Production Safe Scanning

StackHawk’s Production Safe scan policy (DEFAULT_PASSIVE_ONLY) runs only passive analysis against your application — no attack payloads, no exploitation attempts, no data modification. It’s designed for environments where availability and data integrity are critical, like production.

Why It’s Safe for Production

Traditional dynamic application security testing (DAST) tools use active scanning — sending crafted attack payloads like SQL injection strings, XSS vectors, and fuzzing data to probe for vulnerabilities. While effective at finding bugs, active scanning can insert junk data into databases, trigger error states, or degrade performance.

Production Safe scanning takes a fundamentally different approach. It sends only standard HTTP requests to your application — the same kind of requests a normal user or API consumer would make. It then analyzes the responses for security issues without ever attempting to exploit them.

What Production Safe scanning does NOT do:

• Send attack payloads or exploitation attempts
• Insert, modify, or delete data in your application
• Fuzz input parameters with malformed data
• Generate high volumes of aggressive test traffic
• Attempt to bypass authentication or authorization controls

What it DOES do:

• Send standard HTTP requests to your application’s endpoints
• Analyze HTTP response headers, cookies, and body content
• Check for security misconfigurations and information disclosure
• Identify missing security controls and best-practice violations

What It Detects

Even without active exploitation, passive analysis catches a wide range of security issues by examining how your application responds to normal traffic:

Security Header Configuration

Missing or misconfigured headers that leave your application exposed — including HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy.

Cookie Security

Cookies missing critical security flags like HttpOnly, Secure, and SameSite — which can lead to session hijacking and cross-site attacks.

Information Disclosure

Sensitive data leaked in HTTP responses: internal IP addresses, stack traces, debug error messages, server version strings, and other information that helps attackers map your infrastructure.

TLS/SSL Configuration

Weak or outdated transport layer security settings that could expose traffic to interception.

Application Security Misconfigurations

Issues like open redirects, cacheable sensitive content, cross-domain misconfigurations, and insecure CORS policies.

Enabling Production Safe Scanning

Set the policyName in your stackhawk.yml configuration:

hawk:
  scan:
    policyName: "DEFAULT_PASSIVE_ONLY"

You can also apply the Production-Safe policy to specific applications through the Policy Management UI in the StackHawk platform.

When to Use Production Safe Scanning

• Production environments — where data integrity and uptime are non-negotiable
• Staging environments mirroring production — when the staging database contains real or sensitive data
• Regulated environments — where compliance requirements restrict the types of testing allowed
• Continuous monitoring — running scans on a schedule to catch configuration drift

For pre-production environments (local development, CI/CD pipelines, dedicated test environments), we recommend using a full scan policy to get the deepest vulnerability coverage. See StackHawk Policies for all available policies.