API Security: Security Team’s Playbook

TL;DR

• Treat APIs as first class assets. Maintain an API inventory with owner, contract, risk, last seen, and data classes across all environments.
  
• Establish a minimum viable control set. Short lived tokens with audience and issuer checks, object level authorization on money and identity flows, schema validation, write rate limits, webhook signatures, masking in logs.
  
• Make policy a product. Keep rules in version control, test them like code, promote with the pipeline, and attach evidence.
  
• Detect what attackers do early. Alert on 403 spikes, sequential ID access, schema violation bursts, tokens reused across services, repeated webhook IDs.
  
• Prove it. Automate an evidence pack from configs, test results, rule files, and dashboards so questionnaires and audits move fast.
  

Who this is for, and how to use it

This playbook is for security engineers, detection engineers, GRC, and incident responders. Use it to define a consistent control baseline, wire detection and response into the pipeline, and produce audit-ready evidence without spreadsheet hunts. Pair each section with a short checklist you can track in your backlog.

One-page SOC snapshot

Keep one slide up to date for leadership and weekly ops.

• Coverage. Percent of internet facing routes with owner, contract, and enforced policy.
  
• Protection. Access failure incidents, replay blocks, schema violations.
  
• Speed. Drift time to detect, MTTR, time to revoke and rotate.
  
• Evidence. Freshness score of the audit pack.
  
• Top risks. Three routes with highest combined risk and their owners.
  

Why APIs, why now for security

Most traffic is machine to machine and always on. Interfaces change weekly. Attackers do not need exotic exploits when they can enumerate endpoints, try neighbor identifiers, replay events, or mine verbose logs. Your program must see every endpoint, validate identity and ownership consistently, prevent common abuse, and turn runtime truth into policy and tests.

Threat model in practice

• BOLA and IDOR. Missing ownership checks on reads and writes.
  
• Mass assignment. Extra fields accepted and honored.
  
• Token misuse. Long lived tokens, audience or issuer not verified, reuse across services.
  
• Parser exhaustion. Oversized or deeply nested payloads.
  
• Webhook replay and spoofing. No signatures, stale timestamps, no idempotency.
  
• Version drift. Old routes kept alive, undocumented endpoints.
  
• Data exposure. PII in logs, verbose error messages.
  

Counter moves. Contract first design, strict schemas, short lived tokens with audience and issuer checks, object level authorization, rate limiting and normalization, replay guards, and privacy by default in telemetry.

Control baseline by lifecycle

Design

• Classify data per field in the contract.
  
• Require security schemes and scopes in specs.
  
• Name an owner per service, route, and version.
  
• Publish deprecation windows and removal criteria.
  

Build

• Secrets out of code with rotation.
  
• Shared token validation libraries.
  
• Strict types, unknown fields blocked by default.
  
• Policy bundles for gateway and mesh checked into the repo.
  

Test

• Negative tests for cross tenant access, overposting, wrong or expired tokens.
  
• Fuzz encoders and limits on depth, cost, size.
  
• Nightly synthetic abuse tests on money and identity flows.
  

Ship

• Canary with shadow contract validation.
  
• Gate promotion on violation budgets, not gut feel.
  
• Track adoption of policy bundles by service.
  

Runtime

• Audience, issuer, expiration validated on every call.
  
• Object ownership enforced on read and write.
  
• Write route rate limits and request normalization.
  
• Webhook HMAC with timestamp and five minute window.
  
• Correlation IDs and principal context in logs.
  

Govern

• Policy and evidence in version control with history.
  
• Quarterly review of drift, SLOs, and deprecation progress.
  
• Customer facing security page updated with real metrics.
  

Policy as code, quick examples

OPA Rego, object ownership check

package api.authz

default allow = false

allow {
  input.method == "GET"
  input.path = ["v1","accounts", acc_id]
  input.user.tid == data.accounts[acc_id].tenant
  input.user.sub == data.accounts[acc_id].owner
}

Envoy rate limit and schema gate (fragment)

typed_per_filter_config:
  envoy.filters.http.ratelimit:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit
    domain: "public-api"
    rate_limited_as_resource_exhausted: true
# Pair with an external schema validator or contract-aware filter

GraphQL, persisted queries only

import { ApolloServer } from "@apollo/server";
import { createPersistedQueryPlugin } from "@apollo/server-plugin-persisted-queries";
const server = new ApolloServer({ typeDefs, resolvers, plugins: [createPersistedQueryPlugin()] });

Detection engineering

Log the right things

• Correlation ID and parent span ID
  
• Route and version
  
• Principal and tenant identifiers
  
• Decision and reason
  
• Mask flags for PII
  

{"ts":"2025-09-04T10:12:00Z","corr":"c-7ad2","route":"GET /v1/orders/321","principal":"sub:u-88","tenant":"t-5","decision":"deny","reason":"owner_mismatch","pii_masked":true}

Detections to wire

• 403 spikes by route and principal
  
• Sequential access to object IDs
  
• Tokens seen across services within short windows
  
• Bursts of schema violations on a route or version
  
• Repeated webhook IDs or timestamp skew
  

Elastic style query sketch

event.type:api AND http.response.status_code:403
| stats count() by route, principal over 5m
| where count > baseline(route, principal) * 3

Sigma style rule sketch

title: Webhook Replay Attempts
logsource:
  category: webserver
detection:
  sel:
    http.request.headers.X-Signature: "*"
  condition: selection and count_by(source_ip, X-Event-Id) > 1 within 5m
fields: [route, source_ip, X-Event-Id]
level: medium

Incident response playbooks

Access control failure on account data

1. Contain. Block the route or add a temporary allowlist and lower rate limits.
   
2. Revoke. Rotate affected tokens and keys.
   
3. Investigate. Query logs for neighbor ID access and scope by tenant.
   
4. Fix. Add and test ownership checks, ship as policy and test.
   
5. Notify. Customers and regulators per jurisdiction.
   
6. Learn. Add a negative test to CI and a detection to the SOC runbook.
   

Webhook replay on payments

1. Contain. Enable signature enforcement and short replay window.
   
2. Sweep. Deduplicate with idempotency keys and reconcile state.
   
3. Fix. Store last seen IDs per sender and enforce freshness.
   
4. Prove. Attach logs and rules to the evidence pack.
   

Keep runbooks in the repo. Link queries and dashboards, not just prose.

Discovery and inventory

API-BOM fields to capture

service, path, method, version, owner, data_class, auth, pii_fields, last_seen, risk

Sources to triangulate

• Gateway logs and configs
  
• Mesh telemetry and certificates
  
• Traffic based discovery
  
• Spec repositories and code search
  

Alert on endpoints with no owner, routes that differ from the contract, and versions with stale traffic.

Privacy and data handling

• Do not export payloads to vendor clouds when analyzing traffic.
  
• Mask PII in logs and traces, tokenize when you must join.
  
• Keep debug retention short.
  
• Prove deletion with job logs and checks.
  
• Store a data map per service, fields, purpose, retention, and lawful basis.
  

Evidence and compliance

Create an automated evidence pack and keep it fresh.

• Policy files and versions
  
• Token validation and cipher configs
  
• Contract files and lint results
  
• Negative test results and fuzz summaries
  
• Drift and incident dashboards with dates
  
• Deprecation calendar and removal proofs
  
• Data deletion logs and retention configs
  

This replaces ad hoc spreadsheets and shortens questionnaires.

KPIs for the security program

• Coverage of routes with owner, contract, and enforced policies
  
• Access failure incidents per quarter and replay blocks
  
• Drift time to detect and MTTR
  
• Percent of services using policy bundles
  
• Evidence freshness and audit pass rate
  

A first 90 days day plan

30 days, visibility and quick wins

• Build API-BOM for top revenue and identity flows.
  
• Enforce token checks on critical routes and shorten lifetimes.
  
• Turn on write limits and request normalization.
  
• Mask PII in logs.
  
• Deliverable, KPI baseline and named owners for gaps.
  

60 days, enforce and measure

• Add ownership checks on money and account flows.
  
• Wire negative tests into CI.
  
• Add detections for 403 spikes, schema bursts, and webhook replays.
  
• Deliverable, before and after metrics for incidents and support tickets.
  

90 days, prove and optimize

• Automate the evidence pack for PCI, SOC 2, and privacy.
  
• Retire zombie versions per the deprecation calendar.
  
• Publish a security page with concrete improvements and dates.
  

RACI with platform and product

• Security. Rules, evidence, violation budgets, detections, incident playbooks.
  
• Platform. Shared libraries, policy bundles, CI jobs, discovery sensors.
  
• Service teams. Adopt bundles, implement ownership checks, own routes.
  
• SRE. Gateway and mesh operations, rollback and recovery, telemetry.
  
• Product. Deprecation windows, partner comms.
  

Market gaps to expect, neutral view

• Tools that require payload export increase privacy and legal risk.
  
• Detection only products produce noise and no durable fixes.
  
• Per-request billing punishes testing and success.
  
• Limited coverage for GraphQL, webhooks, and AI endpoints leaves blind spots.
  
• No single source of truth linking runtime, CI, and evidence slows audits.
  

Buyer’s guide for security teams

• Does discovery come from real traffic as well as specs
  
• Can contracts be validated in real time without moving payloads out of boundary
  
• Can findings auto-generate policies and tests inside our pipelines
  
• How predictable is pricing across services and environments
  
• What evidence exports exist and are auditors accepting them
  
• How complete is support for REST, GraphQL, gRPC, webhooks, and AI endpoints

Ask for a proof on one high risk flow with before and after metrics.

Anti-patterns to retire

• Custom token parsing scattered across services
  
• Schema checks only at the edge
  
• Long lived tokens and static secrets
  
• Debug logs with PII kept for months
  
• Staging that is lenient while production is strict
  
• Breaking changes shipped without shadow validation

Introduction to Levo, how we help

Levo gives privacy-preserving runtime visibility and contract validation that stays inside your boundary. Findings turn into policies and CI tests you can adopt service by service, and pricing stays predictable as you grow across services and environments. This lets security teams reduce incidents, accelerate audits, and keep delivery fast.

See how this looks in practice, book a short working session on your two highest risk flows book a demo.

Conclusion

Security teams succeed when controls are portable, tests are reliable, detections are precise, and evidence is automatic. Make these normal and your incident rate falls, audits move faster, and engineering ships with confidence.

Related: Learn how Levo is solving the API security issue with it's fix first approach and a product which is scale agnostic, data privacy first and growth immune pricing Levo's API Solution.