APIs fail in protocol-specific ways: inconsistent HTTP parsing enables request smuggling, and GraphQL and WebSocket services need their own limits and checks.
- Return an accurate
Content-Typeon every response, and make every component parse HTTP messages the same way. - Reject ambiguous framing such as a request with both
Content-LengthandTransfer-Encoding. - Limit GraphQL query depth or cost, and disable introspection in production unless the API is public.
- Use WSS for WebSockets and check the
Originheader during the handshake.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-4.1.1.
V4.1 Generic Web Service Security · 5 requirements
V4.1.1 Level 1
Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml".
V4.1.2 Level 2
Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests, but since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered.
V4.1.3 Level 2
Verify that any HTTP header field used by the application and set by an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend service, cannot be overridden by the end-user. Example headers might include X-Real-IP, X-Forwarded-*, or X-User-ID.
On this site: Maintain an API inventory and prevent gateway bypass (guide)
V4.1.4 Level 3
Verify that only HTTP methods that are explicitly supported by the application or its API (including OPTIONS during preflight requests) can be used and that unused methods are blocked.
V4.1.5 Level 3
Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems.
V4.2 HTTP Message Structure Validation · 5 requirements
For the whole section: Prevent CRLF header injection, log forging and CSV formula injection (guide)
V4.2.1 Level 2
Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using the appropriate mechanism for the HTTP version to prevent HTTP request smuggling. In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length header field is present, the receiver must ensure that it is consistent with the length of the DATA frames.
On this site: Keep HTTP request boundaries consistent across intermediaries (guide)
V4.2.2 Level 3
Verify that when generating HTTP messages, the Content-Length header field does not conflict with the length of the content as determined by the framing of the HTTP protocol, in order to prevent request smuggling attacks.
On this site: Keep HTTP request boundaries consistent across intermediaries (guide)
V4.2.3 Level 3
Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with connection-specific header fields such as Transfer-Encoding to prevent response splitting and header injection attacks.
On this site: Keep HTTP request boundaries consistent across intermediaries (guide)
V4.2.4 Level 3
Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and values do not contain any CR (\r), LF (\n), or CRLF (\r\n) sequences, to prevent header injection attacks.
V4.2.5 Level 3
Verify that, if the application (backend or frontend) builds and sends requests, it uses validation, sanitization, or other mechanisms to avoid creating URIs (such as for API calls) or HTTP request header fields (such as Authorization or Cookie), which are too long to be accepted by the receiving component. This could cause a denial of service, such as when sending an overly long request (e.g., a long cookie header field), which results in the server always responding with an error status.
V4.3 GraphQL · 2 requirements
V4.3.1 Level 2
Verify that a query allowlist, depth limiting, amount limiting, or query cost analysis is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries.
On this site: Apply security limits to GraphQL, WebSocket and gRPC operations (guide)
V4.3.2 Level 2
Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties.
On this site: Apply security limits to GraphQL, WebSocket and gRPC operations (guide)
V4.4 WebSocket · 4 requirements
V4.4.1 Level 1
Verify that WebSocket over TLS (WSS) is used for all WebSocket connections.
On this site: Apply security limits to GraphQL, WebSocket and gRPC operations (guide)
V4.4.2 Level 2
Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application.
On this site: Apply security limits to GraphQL, WebSocket and gRPC operations (guide)
V4.4.3 Level 2
Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this, which comply with the relevant Session Management security requirements.
V4.4.4 Level 2
Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel.
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
Apply security limits to GraphQL, WebSocket and gRPC operations
Carry authorization and resource budgets past the initial HTTP request into resolvers, messages and long-lived streams.
Keep HTTP request boundaries consistent across intermediaries
Trace framing disagreements, reject ambiguous requests and verify what reaches the origin with a real loopback proxy project.
Maintain an API inventory and prevent gateway bypass
Connect documented routes, deployed listeners and backend trust so retired or direct paths do not bypass the intended controls.
Verify webhook deliveries before acting
Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action.
Practice
- Webhook signature and replay lab: Repair a webhook handler that pays twice · Browser lab
- Repair a real proxy and shared cache · Local project
References
- V4 API and Web Service (ASVS 5.0.0 source)
- OWASP REST Security Cheat Sheet
- OWASP Web Security Testing Guide: GraphQL Testing
- OWASP Web Security Testing Guide: Testing WebSockets
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.