Introducing API Security: Access Control Protection

APIs power modern products, but they’re also prime targets for credential stuffing, token abuse, scraping, and volumetric misuse. NOC’s new API Security & Access Control brings authentication and authorization decisions to the edge — before traffic ever reaches origin — so you can protect sensitive endpoints, enforce least-privilege access, and keep latency low.

What’s Included

• API key enforcement: Validate static keys in headers or query strings, with per-key rate limits and revocation.
• JWT validation at the edge: Verify issuer, audience, signature (HS/RS/ES), and TTL; pass verified claims to origin via headers.
• mTLS for service-to-service: Require client certificates for private APIs and partner integrations.
• Allow/Deny controls: CIDR/IP allowlists, country blocks, user-agent and ASN controls.
• Rate limiting & burst control: Global and per-identity (IP, key, sub, org) thresholds with sliding windows.
• Schema & method enforcement: Restrict HTTP methods, paths, and payload size; optional OpenAPI-guided validation.
• CORS & header policy: Strict control over origins, credentials, and caching of preflight.
• Abuse & bot mitigation: Reputation feeds, TLS fingerprinting, and behavior-based challenges before origin.
• Edge logging & analytics: High-fidelity request logs, allow/deny reasons, hit/miss, p95 latency, and policy drill-downs.

Why Edge-First API Protection

Blocking bad traffic after it hits origin wastes compute and invites lateral risk. By validating identity and intent at the edge, NOC reduces origin load, eliminates noisy logs, and gives you consistent controls across regions — critical for multi-cloud and hybrid setups.

Quick Examples

1) Require an API Key on /v1/private/* with Per-Key Limits

{
  "match": { "path": "/v1/private/*" },
  "auth":  { "type": "api_key", "in": "header", "name": "X-API-Key" },
  "limits": { "subject": "api_key", "rate": "300/m", "burst": 100 }
}

2) Validate JWT (RS256) and Pass Claims Upstream

{
  "match": { "path": "/v2/*", "methods": ["GET","POST"] },
  "auth": {
    "type": "jwt",
    "alg": "RS256",
    "jwks_url": "https://idp.example.com/.well-known/jwks.json",
    "aud": "api://example",
    "iss": "https://idp.example.com/"
  },
  "claims_to_headers": ["sub","org","scope"]
}

3) mTLS for Partner Endpoints

{
  "match": { "path": "/partner/*" },
  "mtls":  { "required": true, "ca_bundle": "noc_ca_pool" },
  "limits": { "subject": "cert.fingerprint", "rate": "120/m" }
}

Common Use Cases

• Public APIs: Stop scraping and key abuse; throttle per-consumer; enforce CORS correctly.
• Mobile & SPA backends: Validate JWTs at the edge; forward claims to microservices via headers.
• Partner & B2B: Lock down by mTLS and CIDR; segment per-partner quotas and analytics.
• Internal mesh & hybrid: Use mTLS between clusters and clouds; keep control planes consistent globally.

Best Practices

• Prefer JWT with short TTLs and audience scoping; rotate keys frequently.
• Set per-identity limits (key, sub, org) instead of only IP-based thresholds.
• Separate admin and write endpoints; apply stricter auth and lower limits.
• Cap payload sizes; block unexpected methods and content types by default.
• Monitor deny reasons and near-limit traffic to tune policies safely.

Ready to lock down your APIs without slowing them down? Get in touch and we’ll help you deploy edge policies in minutes.