Hardening MCP Gateways: Mitigating July 28 Security Risks in Java Applications

MCP 게이트웨이의 새로운 보안 위협, Java 백엔드가 준비해야 할 것들

MCP(Model Context Protocol) 사양의 최신 업데이트는 기존 스테이트풀 연결 방식을 버리고 스테이트리스 HTTP 패러다임을 채택함으로써 엔터프라이즈 환경에서의 확장성과 분산 구조 적합성을 크게 높였다. 에이전트 기반 시스템이 내부 데이터베이스, API, 코드 실행 환경과 직접 연동되는 구조가 현실화되면서, Java 백엔드 개발자들이 MCP 게이트웨이를 설계할 때 보안을 단순한 부가 요소가 아닌 핵심 아키텍처 요소로 다뤄야 할 필요성이 생겼다.

새롭게 열린 공격 벡터: 무엇이 문제인가

이번 사양 변경에서 새롭게 도입된 세 가지 기능이 보안 관점에서 특히 주목된다.

커스텀 _meta 페이로드 객체: 요청마다 임의의 메타데이터를 전달할 수 있는 구조로, 검증 없이 내부 로직에 전달될 경우 역직렬화 공격이나 파라미터 오염(parameter pollution)의 진입점이 될 수 있다.
동적 파라미터 라우팅: 요청 파라미터를 기반으로 라우팅 경로가 동적으로 결정되는 방식은 경로 우회(path traversal)나 SSRF(Server-Side Request Forgery) 취약점을 유발할 수 있다.
x-mcp-header 매핑: 커스텀 헤더를 내부 시스템의 요청 컨텍스트에 매핑하는 기능은, 헤더 인젝션을 통해 인증 우회나 권한 상승으로 이어질 수 있다.

스테이트리스 구조의 본질적 특성상 요청 간 컨텍스트를 공유하지 않기 때문에, 모든 보안 검증이 요청 단위로 완결되어야 한다. 이는 기존 세션 기반 인증 모델에 익숙한 Java 백엔드 개발자들에게 설계 패러다임의 전환을 요구한다.

Java 백엔드에서의 방어 전략

MCP 게이트웨이를 Spring 기반으로 구현할 때, 각 신규 기능에 대한 방어 레이어를 명시적으로 구성해야 한다.

_meta 객체는 역직렬화 시 허용 타입을 명시적으로 제한하고, 알 수 없는 필드를 무시하는 설정을 강제해야 한다.

@JsonIgnoreProperties(ignoreUnknown = true)
public class McpMetaPayload {
    private String requestId;
    private String traceContext;
    // 허용된 필드만 명시적으로 선언
}

동적 파라미터 라우팅 경로는 사전에 정의된 허용 목록(allowlist)과 대조 검증하는 필터를 게이트웨이 레이어에 배치해야 한다. x-mcp-header 매핑의 경우, 내부 시스템에 전달 가능한 헤더 키를 화이트리스트로 관리하고 나머지는 드롭하는 인터셉터를 구성하는 것이 효과적이다.

@Component
public class McpHeaderValidationInterceptor implements HandlerInterceptor {
    private static final Set<String> ALLOWED_MCP_HEADERS =
        Set.of("x-mcp-trace-id", "x-mcp-client-version");

    @Override
    public boolean preHandle(HttpServletRequest request, ...) {
        String mcpHeader = request.getHeader("x-mcp-header");
        if (mcpHeader != null && !ALLOWED_MCP_HEADERS.contains(mcpHeader)) {
            response.sendError(HttpStatus.BAD_REQUEST.value(), "Unauthorized MCP header");
            return false;
        }
        return true;
    }
}

에이전트가 코드 실행이나 DB 쿼리 권한을 갖는 경우라면, 게이트웨이 레이어에서 요청 단위 권한 검증(per-request authorization)과 함께 감사 로그(audit log)를 반드시 함께 구성해야 한다.

스테이트리스 구조가 가져오는 보안 부담

스테이트리스 설계는 수평 확장과 장애 격리 측면에서 분명한 이점을 제공한다. 그러나 세션 상태에 의존하던 기존 보안 모델을 그대로 적용할 수 없다는 점에서, 보안 처리 비용이 각 요청에 분산된다. 토큰 검증, 권한 확인, 페이로드 무결성 검사 등 모든 작업이 요청 수명 주기 내에서 완결되어야 하므로, 이를 위한 경량화된 보안 파이프라인 설계가 필수적이다.

MCP 게이트웨이가 내부 시스템의 실질적인 진입점이 되는 순간, 보안 설계의 복잡도는 일반적인 REST API 수준을 넘어선다. 신규 기능이 제공하는 유연성만큼 공격 표면도 넓어진다는 점을 전제로 아키텍처를 수립해야 한다.

정리

_meta 페이로드, 동적 라우팅, x-mcp-header 매핑은 MCP의 확장성을 높이지만, 각각 역직렬화 공격, SSRF, 헤더 인젝션의 잠재적 진입점이 된다.
스테이트리스 구조에서는 모든 보안 검증이 요청 단위로 완결되어야 하며, 세션 기반 보안 모델을 그대로 적용할 수 없다.
Java 게이트웨이 구현 시 허용 목록 기반의 입력 검증, 헤더 화이트리스트 인터셉터, 요청 단위 권한 검증을 핵심 방어 레이어로 구성해야 한다.