MCP 보안 하드닝 2026

고급 9 min

최신 스펙 기준으로 인증 흐름, transport 보안, 민감 도구 권한 정책을 단계별로 강화합니다.

MCP보안OAuthOrigin 검증

Transport 보안 기초

The MCP specification defines two transport mechanisms: stdio (local) and Streamable HTTP (remote). Each has distinct security considerations. Stdio transport inherits the security properties of the parent process — it runs with the same permissions and can access the same files. Streamable HTTP transport exposes your MCP server over the network, requiring explicit security measures. For Streamable HTTP, always enforce HTTPS in production. The spec mandates Origin header validation on every request to prevent DNS rebinding attacks. Implement this check as the first middleware in your request pipeline. Requests without a valid Origin header should be rejected with a 403 status. Session management is equally critical. The Mcp-Session-Id header must be generated with sufficient entropy (use UUIDv4 or equivalent), validated on every request, and cleaned up when sessions end via DELETE requests. Never store sensitive data in the session ID itself — use it as a lookup key to server-side session state.

// Streamable HTTP transport security middleware
import { randomUUID } from 'crypto';

const ALLOWED_ORIGINS = new Set([
  'https://claude.ai',
  'https://your-app.example.com',
]);

function validateOrigin(req, res, next) {
  const origin = req.headers.origin;
  if (origin && !ALLOWED_ORIGINS.has(origin)) {
    return res.status(403).json({
      error: 'Forbidden',
      message: 'Origin not allowed',
    });
  }
  next();
}

function sessionMiddleware(req, res, next) {
  if (req.method === 'POST' && !req.headers['mcp-session-id']) {
    // New session — generate ID
    const sessionId = randomUUID();
    res.setHeader('Mcp-Session-Id', sessionId);
    sessions.set(sessionId, { created: Date.now() });
  }
  next();
}

// Apply to MCP endpoint
app.use('/mcp', validateOrigin, sessionMiddleware);

OAuth 2.1과 OIDC Discovery

The MCP spec (2025-11-25 revision) requires servers that use OAuth to support OIDC Discovery. This means your authorization server must expose a .well-known/openid-configuration endpoint that clients can use to automatically discover authorization endpoints, supported grant types, and available scopes. Implement the Authorization Server Metadata endpoint (RFC 8414) alongside OIDC Discovery. This provides clients with the information they need to initiate authorization flows without hardcoded endpoint URLs. The metadata document must include issuer, authorization_endpoint, token_endpoint, and supported scopes. For MCP specifically, use the authorization_code grant type with PKCE (Proof Key for Code Exchange). This is the recommended flow for interactive clients. Avoid client_credentials grants unless your MCP server is used exclusively in server-to-server contexts. Always validate that the redirect_uri in authorization requests matches a pre-registered value exactly — no wildcard matching.

// .well-known/openid-configuration
{
  "issuer": "https://mcp.example.com",
  "authorization_endpoint": "https://mcp.example.com/oauth/authorize",
  "token_endpoint": "https://mcp.example.com/oauth/token",
  "registration_endpoint": "https://mcp.example.com/oauth/register",
  "scopes_supported": [
    "mcp:tools:read",
    "mcp:tools:execute",
    "mcp:resources:read"
  ],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code"],
  "code_challenge_methods_supported": ["S256"],
  "token_endpoint_auth_methods_supported": ["none"]
}

// Protected Resource Metadata (RFC 9728)
// /.well-known/oauth-protected-resource
{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://mcp.example.com"],
  "scopes_supported": ["mcp:tools:read", "mcp:tools:execute"],
  "resource_documentation": "https://docs.example.com/mcp-api"
}

Incremental Consent와 스코프 최소화

The incremental consent model introduced in the 2025-11 MCP spec update allows clients to request additional scopes as needed, rather than asking for all permissions upfront. This follows the principle of least privilege — your MCP server should start with minimal scopes and only request more when a specific tool requires elevated access. Map each tool to its required scopes explicitly. When a client calls a tool that requires a scope they haven't granted yet, respond with an appropriate error that indicates which additional scope is needed. The client can then trigger a new authorization flow for just that scope, preserving all previously granted permissions. Audit your scope definitions regularly. Avoid broad scopes like 'admin' or 'full-access'. Instead, use granular scopes that map to specific capabilities: 'tools:database:read', 'tools:database:write', 'resources:files:list'. This granularity makes consent dialogs more meaningful to users and reduces the blast radius of compromised tokens.

// Tool-to-scope mapping
const TOOL_SCOPES = {
  'query-database': ['mcp:tools:db:read'],
  'write-database': ['mcp:tools:db:read', 'mcp:tools:db:write'],
  'list-files': ['mcp:resources:files:list'],
  'read-file': ['mcp:resources:files:read'],
  'deploy': ['mcp:tools:deploy:execute'],  // high-privilege
};

// Middleware: check scopes before tool execution
function requireScopes(toolName) {
  return (req, res, next) => {
    const requiredScopes = TOOL_SCOPES[toolName] || [];
    const grantedScopes = req.auth.scopes;
    const missing = requiredScopes.filter(s => !grantedScopes.includes(s));

    if (missing.length > 0) {
      return res.status(403).json({
        error: 'insufficient_scope',
        required_scopes: missing,
        message: 'Additional authorization required. Re-authenticate with the listed scopes.',
      });
    }
    next();
  };
}

보안 체크리스트와 모니터링

Use this checklist before deploying any MCP server to production. Each item addresses a specific attack vector identified in real-world MCP deployments. The checklist is organized by priority — critical items first, then hardening measures that reduce blast radius. Beyond the checklist, implement ongoing monitoring. Log all tool invocations with timestamps, client identifiers, and scope usage. Set up alerts for unusual patterns: sudden spikes in tool calls, access from unexpected origins, or repeated authorization failures. These signals can indicate compromised credentials or misconfigured clients. Rotate secrets regularly. OAuth client secrets, session signing keys, and API tokens should have defined lifetimes. Automate rotation where possible and ensure your MCP server handles key rollover gracefully — support multiple valid signing keys during the rotation window.

# MCP Security Hardening Checklist

## Critical (Must Have)
- [ ] HTTPS enforced for all Streamable HTTP endpoints
- [ ] Origin header validation on every request
- [ ] Mcp-Session-Id with sufficient entropy (UUIDv4+)
- [ ] PKCE required for OAuth authorization_code flow
- [ ] Input validation on all tool parameters

## Authentication & Authorization
- [ ] OIDC Discovery endpoint (.well-known/openid-configuration)
- [ ] Protected Resource Metadata (RFC 9728)
- [ ] Per-tool scope mapping (no wildcard scopes)
- [ ] Incremental consent flow tested
- [ ] Token expiry < 1 hour, refresh token rotation enabled

## Transport Hardening
- [ ] DNS rebinding protection (validate Host header)
- [ ] CORS restricted to known origins
- [ ] Rate limiting per session (100 req/min default)
- [ ] Request size limits (1MB default)
- [ ] Session cleanup on DELETE and timeout (30 min)

## Monitoring & Audit
- [ ] All tool calls logged with client ID + timestamp
- [ ] Failed auth attempts tracked and alerted
- [ ] Scope usage analytics dashboard
- [ ] Secret rotation automated (90-day cycle)
- [ ] Incident response runbook documented

실행 미리보기

MCP 보안 하드닝 2026