asvs/v4-api-and-web-service

16 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V4.1.1 Content-Type header with charset

Requirement 4.1.1 applies to Level 1. Every HTTP response with a message body must contain 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 HTTP to HTTPS redirect for user-facing endpoints only

Requirement 4.1.2 applies to Level 2. Only user-facing endpoints intended for manual web-browser access should automatically redirect from HTTP to HTTPS. Other services or endpoints must not implement transparent redirects to avoid situations where a client erroneously sends unencrypted HTTP requests that are redirected to HTTPS, causing sensitive data leakage to go undiscovered.

V4.1.3 Intermediary HTTP headers cannot be overridden

Requirement 4.1.3 applies to Level 2. Any HTTP header field used by the application and set by an intermediary layer such as a load balancer, web proxy, or backend-for-frontend service cannot be overridden by the end-user. Example headers include X-Real-IP, X-Forwarded-*, or X-User-ID.

V4.1.4 Only explicitly supported HTTP methods allowed

Requirement 4.1.4 applies to Level 3. Only HTTP methods that are explicitly supported by the application or its API, including OPTIONS during preflight requests, can be used and unused methods must be blocked.

V4.1.5 Per-message digital signatures for sensitive requests

Requirement 4.1.5 applies to Level 3. Per-message digital signatures must be 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.1 HTTP message boundary determination to prevent smuggling

Requirement 4.2.1 applies to Level 2. All application components including load balancers, firewalls, and application servers must 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.

V4.2.2 Content-Length consistency to prevent smuggling

Requirement 4.2.2 applies to Level 3. When generating HTTP messages, the Content-Length header field must not conflict with the length of the content as determined by the framing of the HTTP protocol, in order to prevent request smuggling attacks.

V4.2.3 No connection-specific headers in HTTP/2 or HTTP/3

Requirement 4.2.3 applies to Level 3. The application must 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.

V4.2.4 HTTP/2 and HTTP/3 headers without CR, LF, or CRLF

Requirement 4.2.4 applies to Level 3. The application must only accept 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 Prevent overly long URIs and HTTP headers

Requirement 4.2.5 applies to Level 3. If the application (backend or frontend) builds and sends requests, it must use 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 prevents denial of service such as when sending an overly long request like a long cookie header field which results in the server always responding with an error status.

V4.3.1 GraphQL query allowlist, depth limiting, or cost analysis

Requirement 4.3.1 applies to Level 2. A query allowlist, depth limiting, amount limiting, or query cost analysis must be used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries.

V4.3.2 GraphQL introspection disabled in production

Requirement 4.3.2 applies to Level 2. GraphQL introspection queries must be disabled in the production environment unless the GraphQL API is meant to be used by other parties.

V4.4.1 WebSocket over TLS (WSS) required

Requirement 4.4.1 applies to Level 1. WebSocket over TLS (WSS) must be used for all WebSocket connections.

V4.4.2 Origin header validation during WebSocket handshake

Requirement 4.4.2 applies to Level 2. During the initial HTTP WebSocket handshake, the Origin header field must be checked against a list of origins allowed for the application.

V4.4.3 Dedicated WebSocket session management tokens

Requirement 4.4.3 applies to Level 2. If the application's standard session management cannot be used, dedicated tokens must be used for WebSocket sessions, which comply with the relevant Session Management security requirements.

V4.4.4 WebSocket tokens validated through authenticated HTTPS

Requirement 4.4.4 applies to Level 2. Dedicated WebSocket session management tokens must be initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel.

Give your agent this brain