OWASP API Security Alignment

This page describes the controls the platform implements for each risk of the OWASP API Security Top 10 and the OWASP ASVS requirements each control corresponds to. Each statement describes the behaviour of the control.

Documents and versions

The API Top 10 gives the structure of the page: one section per risk. The ASVS requirement identifiers under each section are the verifiable requirements the described controls correspond to.

Scope

API1:2023 Broken Object Level Authorization

• The tenant is resolved from the validated JWT, never from a request body.
• Every tenant-scoped data query is restricted to the tenant of the caller.
• The crypto path decides authorization through fail-closed gates: capability grants and the key lifecycle policy are evaluated before an operation runs, and an empty or unverifiable authorization record denies.
• Authorization records distributed between platform services are signed: only the administration service holds the private signing key, every reader verifies the signature, and a reader refuses a value it cannot verify.

ASVS 5.0.0: V8.2.2, V8.3.1.

API2:2023 Broken Authentication

• Token validation (every service that accepts user tokens): signature under the key of a registered issuer, iss, aud, exp and nbf with zero leeway. Every token must carry exp, whichever key source verifies it; a token without exp is refused. This is stricter than RFC 7519 §4.1.4 and ASVS V9.2.1, which judge exp when it is present. A non-canonical token, including an unsecured alg: none token, is refused before parsing.
• Algorithm allow-list: platform tokens are signed RS256 with RSA-3072 keys, generated per environment, and verified with an RSA verifier only. The authentication service publishes its signing keys as a JWK Set, each identified by kid.
• Lifetime and revocation: the access-token lifetime defaults to 900 seconds. Revocation is consulted after every claim check and fails closed. Refresh tokens rotate atomically.
• Brute force and credential stuffing: logins are rate-limited per account, and requests to the authentication service are rate-limited per client. An authenticator locks after repeated failed attempts within a time window, counted per authenticator kind (a password or TOTP code per client network), so a lock of one never refuses another; password and TOTP failures from networks the account does not usually sign in from also count toward an account-wide ceiling. The rate limits and the lockout thresholds are configurable by the platform operator.
• Password storage: PBKDF2-HMAC-SHA256 with a 16-byte random salt. Passwords of 15 to 128 characters are accepted, with no composition rule and an offline blocklist of common and compromised passwords (NIST SP 800-63B-4).
• Multi-factor authentication: passkeys (WebAuthn, phishing-resistant) and TOTP, enforced at sign-in by the authentication transaction; platform administrators sign in with a passkey or with password + TOTP, a passkey offered first. TOTP codes are single-use per time step.

ASVS 5.0.0: V9.1.2, V9.2.1, V9.2.3, V6.3.1, V6.2.9, V11.4.2.

API3:2023 Broken Object Property Level Authorization

• Each operation has its own request model, validated on input, separate from the persistence model.
• Where the field set of a request is security-relevant, the request is read strictly and unknown members are refused.

ASVS 5.0.0: V8.2.3, V15.3.3.

API4:2023 Unrestricted Resource Consumption

• Edge rate limiting: the environment edge rate-limits the authentication, account, federation and token-introspection endpoints, the administration plane, and the PQC handshake, licensing and audit endpoints. The limits are configurable by the platform operator.
• Application rate limiting in the authentication service (API2 above), answered 429 with Retry-After and application/problem+json.
• Per-key usage ceilings on the crypto plane: every key material can carry a hard and a soft usage limit and an expiry.
• Bounded queries: date ranges and pages are bounded, for example audit session queries span at most 365 days.

ASVS 5.0.0: V2.4.1.

API5:2023 Broken Function Level Authorization

• Method security: every handler requires a scope authority, and scopes are issued as an array claim.
• Internal service-to-service routes each require their own scope and are not reachable from the edge.

ASVS 5.0.0: V8.2.1.

API6:2023 Unrestricted Access to Sensitive Business Flows

• Login, account and federation flows run behind the per-account rate limits, the lockout and the edge rate limits (API2, API4).
• Actor proof verification is bounded by a concurrency limit that answers 429 with Retry-After.
• Key rotation is admitted only when the rotation rule allows the source and target pair: purpose, structure, policy and composite admission.

ASVS 5.0.0: V2.4.1.

API7:2023 Server Side Request Forgery

Outbound destinations configured by tenants or operators — cloud KMS endpoints, SIEM destinations, identity-provider issuers, notification providers — go through one shared set of rules: internal addresses are refused, HTTPS is required, and the connection is made to the address that was checked (DNS pinning), so a name cannot resolve to a different address between the check and the connection.

ASVS 5.0.0: V1.3.6.

API8:2023 Security Misconfiguration

• HTTP method policy: one platform-wide request firewall admits GET, POST, PUT, PATCH, DELETE, OPTIONS and HEAD, before authentication and on every dispatch. Any other method is answered 405 with Allow and application/problem+json. Per-resource method restrictions stay in each service's authorization rules, and every per-endpoint 405 carries Allow as well. The edge also restricts the methods of the authentication endpoints.
• Response headers set by each public API service: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Content-Security-Policy: frame-ancestors 'none', Strict-Transport-Security: max-age=31536000; includeSubDomains, X-XSS-Protection: 0, and Cache-Control: no-store, no-cache, must-revalidate, private. Each header appears once: no proxy layer adds or overrides a header on a relayed response.
• Admin console: an enforced Content-Security-Policy (default-src 'self'; script-src 'self'; … frame-ancestors 'none'; object-src 'none'), with fonts served from the console itself; X-Frame-Options: DENY, Referrer-Policy: no-referrer, Permissions-Policy and Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Errors: every 4xx and 5xx is an RFC 9457 problem document. No public service renders a stack trace or an exception message. In the administration API a path identifier that is a UUID by contract is bound as a UUID, so a malformed value is answered 400.
• Edge: the server version is not disclosed.
• Management endpoints: limited to health, information and metrics.
• CORS: allowed origins are configured per environment.

ASVS 5.0.0: V3.4.1, V3.4.3, V3.4.4, V3.4.5, V3.4.6, V13.4.2, V16.5.1.

API9:2023 Improper Inventory Management

• One documentation hub publishes the Auth, Core, Admin, PQC Handshake and Audit API specifications.
• Every operation of these APIs declares an explicit, stable operationId.
• Internal services publish no port; an environment publishes only its edge.

ASVS 5.0.0: V13.4.5.

API10:2023 Unsafe Consumption of APIs

• Upstream service-to-service failures are re-presented by role: 400, 402, 404, 409 and 422 are propagated, and any other upstream status becomes a 502 naming the upstream by role, with the responding service's own instance and correlation id.
• External token issuers are admitted through their JWK Set, with a bounded refetch rate; egress follows the HTTPS and SSRF rules of API7.

ASVS 5.0.0: V1.3.6.

Transport and secrets

• The environment edge accepts TLS 1.2 and TLS 1.3.
• All internal connections between platform components are TLS-protected, and each service authenticates with its own credential.
• Secrets are supplied to the services as Docker Swarm secrets.
• Audit events carry a keyed integrity signature, applied by the producing platform service and verified on ingestion. It proves that an event was produced by a platform service holding the audit key and was not altered afterwards; it does not identify which platform service produced it.

ASVS 5.0.0: V12.1.1, V13.3.1.

Related pages

• ETSI TS 103 744 Alignment
• FIPS 140-3, Random Bit Generation and Approved Algorithms