API Security

Why APIs need their own scanner

APIs don't have a homepage to crawl from. A traditional DAST crawler sees nothing on api.example.com/ — no links, no forms, just a 404. The interesting attack surface is the endpoints documented in your spec (or discoverable by probing).

Sectora's API scanner takes the spec as input, enumerates every endpoint × method, generates valid sample requests from the schema, and then mutates each request to test for the OWASP API Top 10 issues. Findings include the exact reproduction request, response diff, and a fix suggestion.

Spec sources

If you don't have a spec, the discovery probe brute-forces common patterns (/api/v1/*, /users/:id, /health, etc.) and any endpoints found in HTML/JS bundles from a paired DAST scan.

Configuring an API scan

From Scans → API Scan:

Base URL

Where the API actually lives — e.g. https://api.example.com. Spec files often have a placeholder host (localhost:3000); the base URL override tells Sectora where to actually hit.

Spec content (or upload)

Paste OpenAPI/Postman JSON/YAML inline, point at a URL Sectora fetches (e.g. https://api.example.com/openapi.json), or upload a file. For GraphQL/gRPC, Sectora pulls the schema via introspection/reflection if your endpoint allows it.

Authentication

Four strategies, configurable per scan:

• None — public endpoints only.
• Bearer / API Key — paste the token; Sectora sends it on every request.
• OAuth 2.0 — link a saved AuthProfile (Settings → Auth Profiles). Supports client_credentials and authorization_code grants.
• mTLS — upload client certificate + key for mutual-TLS APIs.

Tokens are AES-256 encrypted at rest (Sectora's BeforeSave hook); decrypted only when running a scan.

Scan scope

• Include / exclude paths — glob patterns to scope the scan. Useful when your spec covers 1000 endpoints but you only want to test 50.
• Max requests per endpoint — caps the fuzz iterations. Default 20 per endpoint × method.
• Rate limit — requests/second to the API. Default 30; lower if your API has its own rate limiting.

What gets tested

The scanner runs every endpoint × method combination through these checks. Findings are deduplicated across endpoints so a single auth-bypass appears once even if reproducible on 50 routes.

OWASP API Security Top 10

JWT-specific tests

When auth uses Bearer tokens, the scanner runs JWT-aware probes:

• alg:none — rebuild the token with header alg=none, no signature. Servers that allow this are catastrophically broken.
• kid traversal — manipulate the kid header for path traversal / SQLi (some JWT libs do filesystem lookups based on kid).
• HMAC vs RSA confusion — sign with the RSA public key as an HMAC secret. Vulnerable libs accept it.
• Expired token — backdate exp; does the server enforce expiry?
• Token substitution — token from user A presented for an endpoint that should reject it.
• Embedded JWK injection — supply a jwk header with attacker's public key; library verifies against the attacker's key.

GraphQL-specific tests

• Introspection exposure — production endpoints should disable __schema queries; if open, attackers learn your full schema.
• Query depth + complexity — burst a deeply-nested query (10+ levels of joins) to test DoS-via-recursion limits.
• Batching abuse — POST 100 queries in a single batch to bypass per-request rate limits.
• Field-level authorization — same BOLA logic as REST, applied to query field paths (e.g. user(id: 1) { password_hash }).
• Mutation idempotency — fire the same mutation twice; does it create duplicates that should have been rejected?
• Subscription auth — connect to a subscription endpoint without auth, see if data flows.

gRPC-specific tests

• Reflection exposure — production servers should disable reflection; with it, the scanner uses the same probes as on a schema-provided run.
• Authentication bypass — call methods without the expected metadata (Authorization header equivalent).
• Stream interruption — bidirectional streams that don't close cleanly on client disconnect, leaking server resources.
• Field-level authorization — same as REST BOLA, applied to proto message fields.
• Message size limits — submit a 100MB request; does the server crash or rate-limit?

WebSocket-specific tests

• Pre-handshake auth — connect without the auth cookie/token. WebSocket auth that runs AFTER upgrade is too late.
• Cross-origin (CSWSH) — open from a different origin; is the connection accepted?
• Message-level authorization — once connected, can user A send messages that should be admin-only?
• Subprotocol confusion — request a different subprotocol than the server expects.
• Compression bomb — send a permessage-deflate payload that decompresses to gigabytes.

Schema enforcement (paired with Shield)

From any API finding, click Add to Shield. Generates a schema-enforcement rule on your Shield site that blocks requests violating the discovered shape. See Schema Enforcement.

Discovery probe (no spec available)

When you don't have an OpenAPI spec, run with Discovery mode. Sectora:

1. Pulls the JS bundles from your paired DAST target (or the API root if it serves a docs page).
2. Parses every fetch / axios / XHR call out of the JS — these are the endpoints your own UI uses.
3. Brute-forces common patterns (/api/v1/{resource}, /users/:id, /health, /openapi.json, /swagger.json, /graphql, etc.).
4. Records every endpoint that returns 2xx, 401, 403 (the 401/403 prove the endpoint exists even when you don't have auth).
5. Outputs a generated OpenAPI spec you can download and refine.

Useful first-step when migrating to spec-driven development — gives you a baseline to clean up rather than authoring from scratch.

CI/CD integration

# .github/workflows/sectora-api.yml
name: Sectora API Security
on:
  pull_request:
    paths:
      - 'openapi.yaml'
      - 'src/api/**'

jobs:
  api:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run API scan against staging
        env:
          SECTORA_API_KEY: ${{ secrets.SECTORA_API_KEY }}
          STAGING_API_TOKEN: ${{ secrets.STAGING_API_TOKEN }}
        run: |
          SCAN_ID=$(curl -sf -X POST https://api.sectora.io/api/v1/api-scans \
            -H "Authorization: Bearer $SECTORA_API_KEY" \
            -d @- <<EOF
          {
            "base_url": "https://api-staging.example.com",
            "spec_url": "https://api-staging.example.com/openapi.json",
            "auth_type": "bearer",
            "auth_token": "$STAGING_API_TOKEN",
            "min_severity": "high"
          }
          EOF
          | jq -r .data.id)

          # Fail PR on new High+ findings vs main
          curl -sf -H "Authorization: Bearer $SECTORA_API_KEY" \
            "https://api.sectora.io/api/v1/api-scans/$SCAN_ID/diff?baseline=main&min_severity=high" \
            | jq -e '.new | length == 0'

Troubleshooting

"Scanner found 0 endpoints"

• Confirm the spec URL is fetchable (no auth needed by Sectora's scanner — or set spec_auth if it's gated).
• Check the spec parses validly — paste it into editor.swagger.io first.
• For Discovery mode without a spec, pair an API scan with a DAST scan of your frontend — the scanner pulls endpoints from JS bundles.

"BOLA tests reporting FPs"

• BOLA tests need two user tokens — one for user A, one for user B. If you only configured one, the scanner can't distinguish "works for me" from "works for everyone". Settings → Auth Profiles → add a second profile.
• Make sure user A and B have different data — both seeing the same empty list isn't informative.

"Scanner is too aggressive — broke my staging DB"

• Lower rate limit and max requests per endpoint.
• Enable the read-only scan profile in Settings → API → defaults. Skips POST/PUT/PATCH/DELETE testing entirely; useful for prod against production-data targets.
• Use the Evidence-only mode — single proof-of-concept request per finding instead of bulk fuzzing.

What's next

• DAST — for the web UI in front of your API.
• Schema Enforcement — block API attacks at the edge.
• Authenticated Scanning — Auth Profiles setup.
• PR Gates — block spec changes that introduce vulns.