How-To
Customize Security Checks

How to Customize Security Checks

NAT's security checks can be enabled, disabled, and tuned to match your specific API type, compliance requirements, and noise tolerance.

Listing available checks

nat checks list

Output example:

ID                          Category           Default   Description
bola                        Authorization      enabled   Broken Object Level Authorization
bfla                        Authorization      enabled   Broken Function Level Authorization
mass-assignment             Authorization      enabled   Mass assignment / over-permissive writes
sql-injection               Injection          enabled   SQL injection in parameters and bodies
nosql-injection             Injection          enabled   NoSQL operator injection
command-injection           Injection          enabled   OS command injection
ssrf                        SSRF               enabled   Server-Side Request Forgery
rate-limit-missing          Resource           enabled   Missing rate limiting
resource-consumption        Resource           enabled   Unrestricted resource consumption
security-misconfiguration   Misconfiguration   enabled   CORS, verbose errors, debug endpoints
tls-issues                  Transport          enabled   TLS version and certificate issues
sensitive-data-exposure     Disclosure         enabled   PII and secrets in responses
introspection-enabled       GraphQL            enabled   GraphQL introspection in production
query-depth                 GraphQL            enabled   GraphQL query depth limit missing

Enabling and disabling individual checks

# Disable a check by ID
nat scan --url https://api.example.com \
  --disable-check tls-issues
 
# Enable a check that is off by default
nat scan --url https://api.example.com \
  --enable-check advanced-ssrf

Disabling entire categories

# Disable all injection checks
nat scan --url https://api.example.com \
  --disable-category injection
 
# Available categories: authorization, injection, ssrf, resource, misconfiguration, transport, disclosure, graphql

Using a check profile

Save a set of check preferences as a named profile:

# ~/.nat/profiles/no-injection.yaml
name: no-injection
description: Skip injection checks (pre-tested by SAST)
disabled_checks:
  - sql-injection
  - nosql-injection
  - command-injection
  - ssrf
nat scan --url https://api.example.com \
  --profile ~/.nat/profiles/no-injection.yaml

Compliance profiles

NAT includes built-in profiles for common compliance frameworks:

Profile nameFocus
owasp-api-top10Full OWASP API Security Top 10 coverage
pci-dssPCI DSS API security controls
hipaaHIPAA-relevant API security checks
soc2SOC 2 Type II relevant checks
minimalCritical and high severity checks only
nat scan --url https://api.example.com --profile owasp-api-top10

Adjusting check aggressiveness

Some checks have configurable aggressiveness levels:

# Set rate-limit testing to aggressive mode
nat scan --url https://api.example.com \
  --check-config rate-limit-missing.aggressiveness=high
 
# Set BOLA testing to use only ID substitution (not fuzzing)
nat scan --url https://api.example.com \
  --check-config bola.method=substitution-only

Suppressing false positives

If a finding is a false positive, suppress it to prevent it from appearing in future scans:

nat findings dismiss --id FINDING_ID \
  --reason false_positive \
  --note "CORS is intentionally open for this public CDN endpoint"

Dismissed findings are tracked and visible in the dashboard under Suppressed Findings.

Suppressed findings are not deleted — they're retained with your justification for audit trail purposes. You can un-suppress a finding at any time.

Configuration file

Set default check preferences in your config file:

# ~/.nat/config.yaml
scan:
  default_profile: owasp-api-top10
  disabled_checks:
    - tls-issues        # handled by infrastructure team
  check_config:
    rate-limit-missing:
      aggressiveness: low

Next steps