API Security Testing: A Series-A Healthtech Case Study
API security testing for this case study revealed a textbook pattern — a platform that grew 3x while the auth model did not. A platform that grew 3x in a year. APIs that grew faster. And an OAuth implementation that started as a weekend hack and stayed.
The API Security Testing Challenge
Three problems compounded:
- Bespoke auth. Tokens were JWTs with a non-standard claim set; rotation was a 5-minute hard cutover with no overlap window. Any production deploy with an auth change risked a brown-out.
- No schema validation. Endpoints accepted whatever the client sent and validated server-side, inconsistently. An IDOR-by-extra-field bug had landed in production once and was caught only because a clinic noticed.
- Rate limiting was per-IP only. Multi-tenant clinics behind shared NAT could either be too lax or trip each other.
Our API Security Testing Approach
We chose to do the VAPT and the refactor in series, not parallel. Doing them in parallel risks chasing bugs in code that is about to be replaced. We did:
- Weeks 1–4: API VAPT against the existing platform. Catalogued findings.
- Weeks 5–10: OAuth2 refactor (Auth0), schema-validation middleware introduction, gateway-level rate-limiting redesign.
- Weeks 11–13: Re-tested everything, fixed remaining issues, ran a final ASVS L2 mapping.
- Week 14: Reporting + handover.
What We Built Beyond API Security Testing
- OAuth2 + OIDC via Auth0 with refresh token rotation, audience claims per service, and a 30-day overlap window for the deprecated bespoke tokens (so clinic integrations could migrate at their own pace).
- API gateway (AWS API Gateway) with per-tenant rate limiting, JWT validation at the edge, and schema validation against OpenAPI 3.1 specs we backfilled for every endpoint.
- Test-suite additions — automated authorisation-by-role tests for the top 40 endpoints, integrated into the CI pipeline.
- OWASP ASVS L2 mapping — evidence pack for the 75% of L2 controls reachable without major architecture changes; the remaining 25% became a 2026 roadmap item.
API Security Testing Outcomes
- 18 critical/high findings remediated from the VAPT — IDORs, mass-assignment vulnerabilities, an SSRF in a webhook handler, two improper-rate-limit chains.
- p99 API latency improved 26% — counter-intuitive but explained: edge JWT validation removed a stack of in-app token-introspection calls, and schema validation rejected malformed requests before they reached business logic.
- OAuth migration: 92% of clinic integrations moved within 30 days; the long tail completed in week 60.
- Zero auth-related production incidents in the 9 months since cutover, against a baseline of 1–2 per quarter previously.
What We'd Do Differently
The OpenAPI specs we backfilled were generated from the live API responses. That worked for happy-path schemas but was lossy for nullable fields and for endpoints with conditional response shapes. We caught the gaps in week 11; future engagements pair generated specs with a 1–2 day developer-team review.
Second: we should have established a 7-day “shadow validate” period for the schema-validation middleware before turning it to enforce. The first day of enforce produced ~40 client errors from one specific clinic that was sending an unexpected null in a deprecated field. Easy fix; avoided entirely with a shadow window.
Stack & Tools
- Auth0 (OAuth2 + OIDC, custom rules for tenant-scoped audiences)
- AWS API Gateway with custom authorizers, per-tenant rate limits
- OpenAPI 3.1 specs + ajv-based schema validation middleware
- Burp Suite Pro, Postman / Bruno, custom GraphQL fuzzers for the GraphQL surface
- OWASP ASVS L2 mapping spreadsheet (we ship this as part of the deliverable)
FAQ
Why pick Auth0 over building OAuth in-house?
Time-to-market and operational risk. A 50-person engineering team should not maintain a production OAuth implementation unless it is their core business. Auth0’s pricing was reasonable for the client’s scale; we revisit annually whether the build/buy calculus has shifted.
Does schema validation slow APIs down?
Net positive in this case — gateway-edge validation rejected malformed requests before they reached app servers, which freed up significant downstream capacity. Latency for valid requests went up by <3 ms; latency for the system as a whole improved because the bad-request hot loop went away.
How did you handle the long tail of clinic integrations?
30-day overlap window with both auth schemes accepted, then 60 more days where the deprecated scheme returned a deprecation header on every response. We helped the integrations team write per-clinic migration emails in week 4. The last clinic moved in week 60; we kept the legacy auth path open until week 64 to be safe.
Was OWASP ASVS L2 a hard target?
L2 is achievable for most reasonably-engineered platforms with a focused 8–12 week effort. L3 requires architectural decisions made earlier (segmented services, hardware-backed key storage in some controls). We map to L2 by default for clients in regulated sectors; L3 becomes a roadmap conversation.
Why API Security Testing Belongs in Every Release Cycle
API security testing in 2026 belongs in the release pipeline, not in the annual VAPT cycle. The growth pattern this healthtech showed — 142 endpoints, 350M monthly calls, bespoke OAuth — is normal for a Series-A platform; the auth-debt that comes with it is also normal. Continuous API security testing (schema validation, rate-limit assertions, authorisation tests in CI) catches the issues VAPT engagements would later find at higher cost. Treat API security testing as engineering hygiene, not a security-team artefact.
Further reading: VITI Security cybersecurity services · OWASP API Security Project.
Need help on something like this? VITI Security works with operators, BPOs, and SMBs across India and abroad.
Discuss an API Engagement
