CCAS study materials
CCAS study resources

CCAS: API Security and Application Integration Security

CCAS · Work through your exam, one topic at a time.

All guide sections

API Security and Application Integration Security

API and integration security concentrates on the interfaces between components: how callers are authenticated, how individual objects are authorized, and how gateways, queues, and webhooks are hardened. Items often present a valid token and ask why access still succeeded.

Core rules

  • The OWASP API Security Top 10 anchors the domain: broken object level authorization (BOLA), broken authentication, broken object property level authorization (mass assignment, excessive data exposure), unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server-side request forgery, misconfiguration, improper inventory management, and unsafe consumption of third-party APIs.
  • OAuth 2.0: authorization code with PKCE for user-facing apps, client credentials for machine-to-machine. Avoid implicit and resource-owner-password grants. Validate tokens completely - signature, issuer, audience, expiry, algorithm - and reject mismatched algorithms.
  • Gateway duties: authentication offload, rate limiting and quotas, schema and size validation, TLS termination, and request logging. Gateway policy never substitutes for object-level authorization in the application.
  • Service-to-service: mTLS with workload identity, short-lived certificates, and default-deny network policy.
  • Integrations: verify webhook signatures and timestamps, guard against replay with idempotency keys, and request narrowly scoped third-party consent.

Worked example

GET /accounts/{id}/statements returns another customer's statement when an authenticated user edits the id. Reasoning: the token is valid, the user is authenticated, and the scope permits reading statements - so authentication and scope checks pass. The failure is that the handler never verifies the account belongs to the token subject. Adding scopes cannot fix this; the scope expresses a verb, not ownership of a specific object. The fix is a centralized server-side ownership check on every object reference, plus tests that iterate IDs across tenants and expect 403.

Traps

Assuming the gateway enforces authorization; validating only the token signature; using scopes as the complete authorization model; confusing 401 and 403 when reading test results; and ignoring API inventory, where deprecated and shadow versions remain live attack surface.