REST API Testing

NAT is purpose-built for REST API security testing. This guide covers how to configure NAT for REST APIs, including spec-based and specless scanning.

Scan modes

Specless scanning (crawl mode)

NAT can discover REST API endpoints without a specification by sending intelligent probe requests and analyzing responses:

nat scan --url https://api.example.com

NAT uses a combination of path enumeration, link following, and response analysis to map your API surface. This works well for many APIs but may miss endpoints with no discoverable links.

Spec-based scanning (recommended)

Providing an OpenAPI 3.x or Swagger 2.x specification gives NAT instant, complete knowledge of every endpoint, parameter, schema, and authentication requirement:

nat scan --url https://api.example.com --spec ./openapi.yaml

The spec can be a local file path or a URL:

nat scan --url https://api.example.com \
  --spec https://api.example.com/openapi.json

Spec-based scanning is 2–3× faster than crawl mode and achieves significantly higher endpoint coverage. Use it whenever your API has an OpenAPI or Swagger spec available.

What NAT tests in REST APIs

NAT covers the full OWASP API Security Top 10:

OWASP Category	What NAT Tests
API1 — Broken Object Level Authorization	Cross-user resource access (BOLA/IDOR)
API2 — Broken Authentication	Token weaknesses, brute force, session flaws
API3 — Broken Object Property Level Authorization	Mass assignment, over-permissive PATCH/PUT
API4 — Unrestricted Resource Consumption	Rate limiting, pagination abuse, large payload DoS
API5 — Broken Function Level Authorization	Admin endpoint access with user credentials
API6 — Unrestricted Access to Sensitive Business Flows	Business logic abuse, workflow bypass
API7 — Server Side Request Forgery	SSRF via URL parameters and webhooks
API8 — Security Misconfiguration	CORS, verbose errors, debug endpoints
API9 — Improper Inventory Management	Shadow endpoints, deprecated API versions
API10 — Unsafe Consumption of APIs	Third-party integration security

Additionally, NAT tests for:

SQL/NoSQL injection in path, query, and body parameters
Command injection
Path traversal
XML/JSON injection
HTTP header injection

Targeting specific endpoints

Include/exclude patterns

# Only test endpoints under /api/v2/
nat scan --url https://api.example.com \
  --spec ./openapi.yaml \
  --include "/api/v2/*"
 
# Skip read-only GET endpoints
nat scan --url https://api.example.com \
  --exclude "GET:*"
 
# Skip a noisy endpoint
nat scan --url https://api.example.com \
  --exclude "/api/v1/health"

Testing specific HTTP methods

# Only test write operations
nat scan --url https://api.example.com \
  --include "POST:* PUT:* PATCH:* DELETE:*"

Handling versioned APIs

NAT handles API versioning automatically when using a spec. For manual control:

# Test multiple versions simultaneously
nat scan --url https://api.example.com \
  --spec ./openapi-v1.yaml \
  --spec ./openapi-v2.yaml

Request body customization

NAT generates test request bodies from your OpenAPI schemas. You can seed it with realistic example values:

nat scan --url https://api.example.com \
  --spec ./openapi.yaml \
  --examples ./test-data.json

The examples file maps schema names to sample values:

{
  "UserCreate": {
    "email": "test@example.com",
    "name": "Test User",
    "role": "viewer"
  }
}

Pagination and large APIs

For APIs with many endpoints, control resource usage:

nat scan --url https://api.example.com \
  --spec ./openapi.yaml \
  --concurrency 3 \
  --rate-limit 10 \
  --max-requests 5000

Output formats

nat scan --url https://api.example.com --format html --open

Opens a full interactive HTML report in your browser.

Next steps

Test an OpenAPI Spec — step-by-step guide
Authentication Configuration — configure auth for your API
CI/CD Integration — run scans on every PR
Reading Risk Reports — interpret scan output

Authentication GraphQL Testing