Security Scanning

This guide explains what NAT scans for, how its AI-powered testing engine works at a high level, and how to configure scans for your security requirements.

OWASP API Security Top 10 coverage

NAT provides full coverage of the OWASP API Security Top 10 (opens in a new tab):

#	Category	What NAT Tests
API1	Broken Object Level Authorization	Can a user access another user's resources by substituting IDs?
API2	Broken Authentication	Weak tokens, missing expiry, brute force, credential stuffing
API3	Broken Object Property Level Authorization	Mass assignment vulnerabilities in PATCH/PUT endpoints
API4	Unrestricted Resource Consumption	Missing rate limits, pagination abuse, large payloads
API5	Broken Function Level Authorization	Users accessing admin-level functions
API6	Unrestricted Access to Sensitive Business Flows	Bypassing business logic gates, workflow manipulation
API7	Server Side Request Forgery	SSRF via URL/URI parameters, webhooks, import features
API8	Security Misconfiguration	Debug endpoints, verbose errors, permissive CORS, missing TLS
API9	Improper Inventory Management	Undocumented endpoints, deprecated API versions
API10	Unsafe Consumption of APIs	Third-party API injection and confused deputy attacks

Additional test categories

Beyond OWASP API Top 10, NAT also tests for:

Injection attacks

SQL injection (all database backends)
NoSQL injection (MongoDB operators, JSON injection)
Command injection via shell-interpolated parameters
LDAP injection
XML/XXE injection
Path traversal (../ and encoded variants)
Template injection (SSTI)

Transport and cryptography

HTTP endpoint exposure (no TLS redirect)
Weak TLS versions (SSLv3, TLS 1.0, TLS 1.1)
Mixed content
Insecure cookies (missing Secure, HttpOnly, SameSite)

Information disclosure

Verbose error messages with stack traces
Sensitive data in responses (PII, secrets, tokens)
Debug endpoints active in production
Technology fingerprinting

How NAT's AI testing engine works

NAT's security engine uses intelligent agents that adapt their testing strategy based on what they discover:

Discovery phase — Agents map the API surface, identifying endpoints, parameters, data types, and authentication requirements
Prioritization — Endpoints are scored by potential risk and resource sensitivity; higher-risk targets get more thorough testing
Active testing — Agents generate and execute targeted test cases, using discoveries from earlier tests to inform later ones
Chaining — When a finding is discovered (e.g., an IDOR), agents automatically probe for related vulnerabilities (e.g., escalating from read to write access)
Reporting — All findings are deduplicated, scored, and formatted with evidence and remediation guidance

NAT does not use brute force or exhaustive fuzzing as its primary strategy. The AI prioritization layer focuses effort where it matters most, keeping scan times reasonable even for large APIs.

Risk scoring

Every finding receives a numeric risk score from 0 to 100 based on:

Factor	Weight
CVSS base score (exploitability × impact)	High
Data sensitivity of affected endpoint	High
Authentication required to exploit	Medium
Network exposure (public vs. internal)	Medium
Presence of active exploit evidence	High

Scores map to severity levels:

Score	Severity
90–100	Critical
70–89	High
40–69	Medium
10–39	Low
0–9	Informational

Tuning scan behavior

Adjusting concurrency and rate limiting

For production APIs, use rate limiting to avoid overwhelming the target:

nat scan --url https://api.example.com \
  --concurrency 2 \
  --rate-limit 5 \
  --timeout 45

Excluding safe endpoints

Exclude endpoints that shouldn't be tested (e.g., payment processors, email sends):

nat scan --url https://api.example.com \
  --exclude "/api/v1/payments/*" \
  --exclude "POST:/api/v1/emails/send"

Setting a fail threshold for CI

Exit with a non-zero code if critical or high findings are discovered:

nat scan --url https://staging.example.com \
  --fail-on high

Dry run (discovery only)

Map the API surface without running any security tests:

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

Understanding false positives

NAT aims for high precision — it only reports findings it can actively verify with evidence. However, some findings may require manual verification:

Business logic findings may require context NAT doesn't have
Rate limiting findings depend on the testing environment having conditions similar to production
CORS findings should be verified against your intended list of allowed origins

To suppress a false positive finding in future scans:

nat findings dismiss --id FINDING_ID --reason "false_positive" --note "CORS policy is intentional"

Next steps

Run a Security Audit (how-to) — step-by-step audit walkthrough
Customize Security Checks (how-to) — enable, disable, tune checks
Read Risk Reports — interpret findings and scores

GraphQL Testing CI/CD Integration