Whatever message this page gives is out now! Go check it out!
Managing browser access
Last update:
May 18, 2026
When MCP endpoints are exposed over HTTP(S), browser-based applications introduce additional security, CORS, and rate-limiting considerations.
Overview
When MCP endpoints are exposed over HTTP(S), you may want to call them directly from browser-based applications (SPAs, dashboards, admin consoles). Browsers add additional concerns:
- CORS (Cross-Origin Resource Sharing)
- Session and token handling
- Rate limiting and abuse prevention from client-side code
Direct browser access vs server-side proxies
Before allowing browsers to call MCP endpoints directly, decide where you want to enforce control and hide sensitive details.
You typically have two options:
Direct browser → MCP server
- Browser JavaScript calls
https://your-mcp-server/mcpdirectly. - The MCP server must handle CORS, authentication from the browser, and request validation.
Browser → App backend → MCP server (recommended for most production scenarios)
- Browser calls your own application backend (REST or GraphQL).
- Your backend makes MCP calls on behalf of the browser.
- The backend enforces business rules, scopes, and hides MCP internals.
If you choose direct browser access, treat MCP as a public-facing API with all associated security and stability requirements.
Managing browser-initiated MCP requests
Authentication and sessions
- Require strong authentication (API keys, OAuth tokens, IMS tokens, and similar mechanisms).
- Avoid relying on client-side secrets; anything in JavaScript can be inspected.
- Tie tokens to specific users, origins, or applications where possible.
CORS (Cross-Origin Resource Sharing)
- Configure CORS headers to allow only approved web origins to call the MCP endpoint.
- Include required methods and headers (typically POST, OPTIONS, Content-Type, and authentication headers).
- Use
Access-Control-Allow-Credentials: trueonly when necessary, and combine it with a specific origin, not*.
Limiting exposure
- Do not expose every tool to the browser.
- Consider separate MCP endpoints or servers for browser usage versus internal usage.
- Tag tools and expose only a subset for browser clients.
Rate limiting and quotas
- Implement rate limiting per user, API key, or IP range (with care, especially behind proxies).
- Monitor usage and error rates, and alert on unusual patterns.
Protecting users and data in the browser context
Allowing browser access to MCP features means that:
- Users can directly trigger actions from their browser.
- Content in the browser may be sensitive, especially if resources or tools expose internal data.
To manage this safely:
- Limit tools available to browser clients to low-risk operations by default.
- Scope resources carefully via roots and custom URI schemes so a browser cannot read arbitrary files or internal system data.
- Confirm destructive actions in the UI (deletions, bulk operations) even if the tool allows them; do not rely solely on the MCP layer.
When to prefer backend-only MCP access
In many cases it is safer to keep MCP access server-side only and never expose MCP endpoints directly to browsers. This is especially true if:
- Tools can modify or delete important data.
- Resources include logs, credentials, or internal configuration.
- You need strong internal auditing and change-approval processes.
In those scenarios:
- The browser calls your own backend API.
- Your backend:
- Validates the request against your business rules.
- Calls MCP tools or resources as needed.
- Returns only filtered, user-appropriate data to the browser.
This approach centralizes request management and leverages established backend security controls while still benefiting from MCP internally.
We're glad. Tell us how this page helped.
We're sorry. Can you tell us what didn't work for you?
Share additional feedback to help us improve.
0/255
|
