Capstone: Conduct an API Security Review

This is the capstone for Phase 6. You will conduct a complete API security review for a fictional company, bringing together everything from this phase: authentication and authorization (Module 6.1), the OWASP API Security Top 10 (Module 6.2), and the gateway, rate-limiting, and key-lifecycle controls (Module 6.3). The deliverable is the same one a GRC Engineer hands to an engineering team and an auditor after assessing an API.

There are many valid approaches. The reference solution is one example of a review that would satisfy auditor scrutiny and hold up in production — it is not the only correct answer. What matters is that your findings are specific, mapped to OWASP categories, and each carries a concrete remediation and the evidence that proves it is fixed. Vague answers like "improve security" or "add auth" will not pass an audit and will not pass here.

Capstone project

This is a portfolio-worthy deliverable. A well-completed API security review demonstrates exactly what hiring managers look for in GRC Engineering candidates: reading a real API surface, mapping weaknesses to a recognized framework, and translating each into a concrete fix plus the audit evidence. Save your completed version — it is a real work product you can reference in interviews.

Presenting 9 critical API findings to the team that shipped them

The company: Lumen Health

Lumen Health is a Series A telehealth startup (60 people) running a multi-tenant patient-records API on AWS. Clinics are tenants; each clinic's staff access their own patients' records through the API, which also powers a patient mobile app and a few third-party integrations (a billing partner, an SMS reminder service). They are preparing for their first SOC 2 Type II audit and a HIPAA assessment, and they have asked you to review the API before the auditors arrive.

The current API surface (excerpt)

AUTH
POST /v2/login                 email + password -> JWT (24-hour expiry, no login rate limit)
Mobile app                     ships with a single shared API key in the app binary
Billing partner                authenticates with the same shared API key, emailed at onboarding

PATIENTS
GET  /v2/patients/{id}         returns patient record; requires valid JWT (any clinic's staff)
GET  /v2/patients?limit={n}    list patients; no maximum on n
PATCH /v2/patients/{id}        binds full JSON body to the record
GET  /v2/patients/{id}         response includes ssn, full insurance_id, internal_notes

ADMIN
POST /v2/admin/export          exports all records for a clinic; checks JWT, not role
POST /v2/webhooks/test         body { "url": "..." }; server POSTs a test event to the URL

INTEGRATIONS
SMS reminders                  Lumen calls a third-party SMS API and trusts its response body

INVENTORY
/v1/patients                   still live on production data; undocumented; no monitoring

GATEWAY / LIMITS
none                           services are called directly; no rate limiting; logs are per-service

Lumen Health API — endpoints, auth, and observed behavior

Your deliverable

Produce the API security review below. It has four parts: (1) the authentication and authorization assessment, (2) the OWASP Top 10 findings, (3) the gateway, rate-limit, and key-lifecycle recommendations, and (4) the evidence artifacts you would collect to prove each control to the SOC 2 / HIPAA auditor. Fill in every section.

Exercise

~30 min

Translate this audit finding into a technical remediation plan

OWASP API Security Top 10 (2023) + SOC 2 Type II + HIPAA Finding

API Security Review for Lumen Health

ID:

CAPSTONE-API-2026

Criterion:

API Security — Full Review

Severity:

N/A — Capstone Review Exercise

Conduct a complete API security review of Lumen Health's multi-tenant patient-records API.

Auditor Notes

Lumen Health is a Series A telehealth startup (60 people) on AWS with a multi-tenant patient-records API serving clinic staff, a patient mobile app, and third-party integrations (billing partner, SMS reminders). Preparing for first SOC 2 Type II + HIPAA. Known issues from the surface: GET /v2/patients/{id} has no per-tenant ownership check (BOLA, API1 — critical for PHI); login has no rate limit and 24h JWT expiry (Broken Auth, API2); responses expose ssn/insurance_id/internal_notes (excessive data exposure, API3); PATCH binds full body (mass assignment, API3); /v2/patients?limit has no cap (API4); /v2/admin/export checks JWT not role (BFLA, API5); /v2/webhooks/test fetches caller-supplied URL (SSRF, API7 — can hit AWS metadata); shared API key in the mobile binary and emailed to the billing partner (Broken Auth / key management — bearer secret, no per-consumer identity, not revocable individually); trusts SMS partner response (Unsafe Consumption, API10); /v1/patients still live (Improper Inventory, API9); no gateway, no rate limiting, per-service logs (API4 + weak evidence). Remediations: per-tenant object authZ; login rate limit + short JWT + refresh; field allow-list on responses and updates; pagination cap; role check on admin/export; URL allow-list blocking link-local/private ranges on webhooks; replace shared key with per-consumer keys (mobile uses OAuth/OIDC user tokens, billing partner gets its own scoped key or mTLS); validate SMS partner responses; inventory + decommission /v1; introduce an API gateway for auth offload, rate limiting, validation, and centralized logging. Evidence: per-object authZ tests, token policy, serializer field allow-lists, gateway rate-limit config, endpoint-role matrix + 403 tests, SSRF block tests, key inventory with rotation/revocation, API inventory, centralized access logs. HIPAA note: PHI makes BOLA/excessive-exposure especially severe; access logging and minimum-necessary access are explicit requirements.

Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.

Loading editor…

What's next

You have completed Phase 6: API Security. The review you just produced is the deliverable a GRC Engineer hands to an engineering team before an audit — findings mapped to OWASP, each with a remediation and the evidence that proves it. You can now read an API surface, identify where authentication, authorization, and resource controls fail, and translate every gap into a concrete fix and an audit artifact. That translation — control requirement to technical implementation to evidence — is the core skill the rest of the bootcamp keeps sharpening.