I85PREP
⌘ K
F5-401 Security Expert study materials
F5-401 Security Expert study resources

F5-401 Security Expert: Application and API Security Architecture

F5-401 Security Expert · Work through your exam, one topic at a time.

All guide sections

Application and API Security Architecture

What the domain tests

This domain is about architecture judgement, not product screens: given web UIs, REST/GraphQL APIs and service-to-service calls, can you place authentication, authorization, schema validation and inspection at the tier where each actually works, and explain why a control placed higher or lower fails?

Core rules

  • Negative vs positive security. Signature sets catch known-bad patterns; a positive model (allowed methods, parameter names, types, lengths, JSON schema, OpenAPI contract) rejects everything not described. APIs should lean on the positive model because the contract is machine-readable.
  • Layered placement. The edge handles volumetric DDoS and bot classification; the API gateway terminates TLS, validates tokens, applies rate limits and schema checks; the application owns business-logic authorization.
  • Authentication is not authorization. Validate JWTs against a fetched JWKS, allowlist algorithms (reject none, block RS/HS confusion), check iss, aud, exp, nbf, then check scopes. Object-level authorization (BOLA/IDOR) still lives in the app - a WAF cannot infer that user A may not read invoice B.
  • Service identity. East-west traffic uses mTLS with short-lived certificates and workload identity; network policy enforces least privilege so a compromised workload cannot reach everything.
  • Protocol awareness. GraphQL needs depth and complexity limits plus field-level authorization; gRPC needs HTTP/2-aware inspection and per-method policy; webhooks need replay protection and signature verification.

Worked example

A mobile client calls /v2/accounts/{id}/statements through an API gateway. The token is a JWT signed RS256. Design: the gateway caches JWKS, rejects any token whose header alg is not RS256, verifies signature and aud=api.example.com, enforces a per-token rate limit, and validates the request against the OpenAPI schema (path parameter must be a UUID, no unknown query parameters). The app then confirms the authenticated subject owns account {id}. Reasoning: the gateway can cheaply reject malformed or forged traffic, but only the app knows the ownership relationship, so that check cannot be moved outward.

Traps that cost marks

Saying a WAF provides API security without discovery, schema enforcement and object-level authorization. Treating API keys as user authentication. Assuming discovery output is a policy rather than an inventory. Designing assume-breach segmentation as one firewall rule. Forgetting that TLS termination points dictate where token inspection can occur.