Apache CXF Documentation

Apache CXF is an open-source services framework for building and deploying web services and REST APIs in Java. It supports multiple programming models and protocols:

Core Programming Models (Frontends)

• JAX-WS: For building SOAP-based web services.
• JAX-RS: For building RESTful services.
• Simple Frontend: For creating clients and endpoints without using annotations.

Key Features

• Development Approaches: Supports both contract-first (generating Java from WSDL or OpenAPI specs) and code-first (generating WSDL or OpenAPI specs from annotated Java classes) workflows.
• Security: Provides support for WS-Security, WS-SecurityPolicy, OAuth 2.0, OpenID Connect (OIDC), JWT, TLS configuration, client certificate authentication, and SAML token handling.
• Spring Boot Integration: Offers dedicated Spring Boot starters for JAX-WS and JAX-RS to enable auto-configured, embedded service deployment.
• Observability: Includes built-in Micrometer integration for collecting metrics (latency, error rates, throughput) compatible with Prometheus and Grafana.
• Protocol & Transport Support: Supports SOAP, XML/HTTP, RESTful HTTP, and CORBA over transports such as HTTP, JMS, and JBI.

Apache CXF provides several security mechanisms, but their effectiveness is strictly conditional on the integrator enabling and correctly configuring them. The core security properties include:

1. Message-level authentication & integrity via WS-Security: When WS-SecurityPolicy or relevant interceptors are configured, CXF verifies signatures and tokens and enforces replay windows.
2. Authorization enforcement: Using interceptors like AbstractAuthorizingInInterceptor, CXF can deny operations if the established identity lacks the required roles.
3. Safe-by-default XML processing: CXF uses secure StAX processing and implements input limits (depth, entity, element, and size) to mitigate XML External Entity (XXE) attacks and XML-bomb Denial of Service (DoS).
4. Transport security support: Support for TLS conduits and listeners with hostname and certificate validation.
5. Robust message parsing: Designed to yield clean SOAP/REST faults for malformed input rather than causing memory corruption or system crashes.

In a CXF application, the primary trust boundary is the endpoint's inbound interceptor chain. Data transitions from untrusted to trusted through the following stages:

1. Wire → StAX/XML Parse: Raw SOAP/XML is parsed. This is a critical surface for XML attacks like XXE (XML External Entity) and DoS (e.g., Billion Laughs). CXF provides input-limit and secure-parsing defaults to mitigate this.
2. Parsed Message → WS-Security: If configured, interceptors verify signatures, encryption, and tokens (SAML, X.509, etc.). Without this, the message is only trusted at the transport layer.
3. Message → Authorization: Authorizing interceptors (e.g., AbstractAuthorizingInInterceptor) map the validated identity to specific roles or permitted operations.
4. REST Body → Provider: JAX-RS providers unmarshal bodies (JSON/XML/multipart) into objects. This is a surface for deserialization attacks and parser-based DoS.
5. Client Conduit → Remote Fetch: When acting as a client, CXF may perform outbound requests to resolve WSDLs, schemas, or MTOM references. If these URLs are attacker-influenced, it creates an SSRF (Server-Side Request Forgery) surface.

Apache CXF is a services framework for building and consuming SOAP (JAX-WS) and REST (JAX-RS) services. It is important to distinguish between the framework's responsibilities and the integrator's responsibilities:

Framework Responsibilities (In-Scope)

CXF provides the mechanisms for security, including:

• Message Pipeline: Interceptor-based processing for SOAP/XML and REST/JSON/Multipart.
• WS-Security: Support for signatures, encryption, and token validation (UsernameToken, SAML, X.509, Kerberos) via WSS4J.
• AuthN/AuthZ: Interceptors for mapping identity to roles (e.g., AbstractAuthorizingInInterceptor).
• Transport: Support for TLS conduits and HTTP transports.
• Input Protection: Mechanisms for XML/JSON parsing and input limits.

Integrator Responsibilities (Out-of-Scope)

CXF is a framework, not a deployed application. The Service Integrator (the developer/operator) is responsible for:

• Configuration: Selecting which transports, interceptors, and WS-SecurityPolicy settings are active.
• Security Posture: Enabling TLS enforcement, configuring WS-Security interceptors, and setting input limits.
• Misconfigurations: Any insecurity resulting from a developer choosing to disable security controls (e.g., trusting all TLS certs or exposing unauthenticated endpoints) is considered an integrator error, not a framework vulnerability.

Component Scope Table

The security envelope of a CXF application is defined by runtime configuration. Developers should focus on the following high-leverage configuration areas to harden their services:

Note: Unconfigured security (e.g., no WS-Security interceptors) defaults to transport-only trust.