Ten scanners, one AI pipeline, zero false positives.

A Content Security Policy is an HTTP response header that tells the browser which sources of scripts, styles, images, and other resources are allowed to load. It is the primary defense against cross-site scripting (XSS). A missing or weak CSP is one of the most common findings in OWASP audits.

Every production website should ship Content-Security-Policy, Strict-Transport-Security (HSTS), X-Frame-Options or CSP frame-ancestors, X-Content-Type-Options: nosniff, Referrer-Policy, and Permissions-Policy. SecurityScanner flags every missing header with severity and a stack-specific fix.

In Next.js 14+, set the CSP in `next.config.js` under the `headers()` async function. SecurityScanner detects Next.js and provides the exact `helmet()`-style header block to drop into your config, including nonce handling for inline scripts.

Yes. HSTS prevents protocol downgrade attacks and cookie hijacking on every site, regardless of size. Most browsers refuse to connect to a domain over HTTP once HSTS is set, even if the user types `http://`. It is one line of configuration and free protection.

HSTS (Strict-Transport-Security) forces browsers to use HTTPS for all future connections to your domain. CSP (Content-Security-Policy) controls which resources the browser is allowed to load over that connection. They address different threat models and should both be set.

SecurityScanner's TLS module validates the certificate chain, expiry date, signature algorithm, and issuer trust for any public URL. Results appear in under 60 seconds alongside the rest of the audit.

TLS 1.2 and TLS 1.3 are secure. TLS 1.0 and TLS 1.1 have been deprecated by every major browser and should be disabled at the load balancer or web server. SecurityScanner reports any TLS 1.0/1.1 handshake as a high-severity finding.

SSL (Secure Sockets Layer) is the predecessor to TLS (Transport Layer Security). SSL 2.0 and 3.0 are obsolete and insecure — when people say 'SSL certificate' today they mean a TLS certificate. The term 'SSL' persists mainly for branding.

Modern CA/Browser Forum rules cap public TLS certificates at 398 days. Apple and Google have pushed for shorter (90-day) lifetimes. SecurityScanner flags certificates that expire within 30 days so you have time to renew before breakage.

Disable any cipher using RC4, 3DES, MD5, SHA-1, or anonymous key exchange. SecurityScanner's TLS module reports the full negotiated cipher suite for the connection and flags anything weak by modern standards.

Reflected cross-site scripting happens when user input from a URL parameter or form field is rendered in the page response without proper sanitization. The malicious script executes in the victim's browser in the context of your domain.

Stored (persistent) XSS happens when attacker-controlled input is saved to a database or file and later rendered to other users without sanitization. It is more dangerous than reflected XSS because it affects every visitor who loads the affected page.

React escapes content by default. Avoid `dangerouslySetInnerHTML`. Use DOMPurify for any HTML you must render from user input. Set a strict Content-Security-Policy header. SecurityScanner detects XSS sinks in JavaScript bundles and reports them with the exact line.

Most modern XSS uses JavaScript, but SVG, CSS expressions (legacy), and HTML attributes like `onerror` and `onload` are also vectors. SecurityScanner's XSS probe tests both JavaScript and event-handler injection across query strings, form fields, and URL fragments.

Yes. XSS is part of OWASP Top 10 2025's A03: Injection category. Every public-facing web app should run an XSS probe on every release. SecurityScanner runs the XSS probe in parallel with the other 9 modules in under 60 seconds.

SQL injection (SQLi) happens when attacker-controlled input is concatenated into a SQL query, letting the attacker alter the query's structure. It can lead to data theft, authentication bypass, or full database takeover.

Use parameterized queries (prepared statements) for every database call. Never build SQL by string concatenation. Use an ORM with proper escaping. Apply the principle of least privilege to database accounts. SecurityScanner flags raw SQL sinks in your code.

Yes. NoSQL injection uses operators like `$gt`, `$ne`, or `$regex` passed into query objects. The fix is the same: validate input types against an explicit schema before passing to the query. SecurityScanner's SQLi probe covers both SQL and NoSQL injection vectors.

Blind SQLi happens when the database error is hidden but the attacker can still infer data from boolean or time-based differences in responses. It is slower but just as dangerous as classic SQLi. SecurityScanner detects blind SQLi through response-time and content-length analysis.

A well-used ORM does — but only when you use its parameter binding. Concatenating user input into a raw query, even through an ORM's escape hatch, reintroduces SQLi. SecurityScanner flags raw query calls in ORM-using codebases.

SecurityScanner detects AWS access keys, Stripe secret keys, GitHub tokens, Slack tokens, Google API keys, private keys (RSA, OpenSSH), JWT signing secrets, OAuth client secrets, and database connection strings. Detection happens by pattern matching and entropy analysis on your site's JavaScript bundles and HTML source.

Run a SecurityScanner audit on the URL where the key is loaded. The Secrets Detection module returns the file, line, and key type within 60 seconds. The Pro and Business plans include stack-aware remediation steps.

Immediately rotate the exposed credential at the issuer (AWS, Stripe, GitHub, etc.). Remove the secret from your code and history. Move secrets to environment variables or a secrets manager. Audit access logs for misuse during the exposure window.

JavaScript shipped to the browser is fully visible to every visitor. A leaked AWS access key can lead to cloud account takeover within minutes — automated scanners scrape the web constantly for exposed credentials.

Yes. Source maps and unminified bundles are scanned with the same pattern library. Public source maps are themselves a leak vector and are flagged separately as a medium-severity finding.

Cross-Origin Resource Sharing (CORS) controls which domains can call your API from a browser. A misconfiguration — usually `Access-Control-Allow-Origin: *` combined with `Allow-Credentials: true` — lets any malicious site read authenticated responses.

Only for fully public APIs that do not require authentication. For any endpoint that returns user-specific data, a wildcard origin is a serious vulnerability. SecurityScanner flags wildcard origins on routes that accept credentials.

Use the `cors` npm package with an explicit allowlist of origins, never `*`. SecurityScanner detects Express apps and provides the exact middleware configuration tailored to your detected origin list.

CORS controls which origins can read responses cross-origin. CSRF (Cross-Site Request Forgery) tricks a logged-in user into making unwanted state-changing requests. Both need protection — CORS via headers, CSRF via tokens or SameSite cookies.

No. CORS is enforced by browsers only. Server-to-server calls and curl requests ignore CORS entirely. SecurityScanner flags any CORS configuration that relies on browser-only enforcement for sensitive endpoints.

`Secure` blocks the cookie from being sent over plain HTTP. `HttpOnly` blocks JavaScript access to the cookie, mitigating XSS-driven session theft. `SameSite` blocks the cookie from being sent on cross-site requests, mitigating CSRF. Every authentication cookie should set all three.

Use `res.cookie(name, value, { httpOnly: true, secure: true, sameSite: 'lax' or 'strict' })`. SecurityScanner flags any authentication cookie missing one of these flags and includes the exact middleware configuration in the finding.

`Lax` allows the cookie on top-level navigations (clicking a link) but blocks it on cross-site subrequests (iframes, images, fetch). `Strict` blocks it everywhere except same-site requests. Use `Strict` for high-value session cookies, `Lax` for general authentication.

Yes — via network sniffing if HTTPS is not enforced, via XSS exploiting a different non-HttpOnly cookie, or via physical access to the device. HttpOnly is necessary but not sufficient. Combine it with HSTS, a strict CSP, and short session lifetimes.

Short — 30 minutes to a few hours for high-value sessions. Use refresh tokens or re-authentication for longer sessions rather than extending cookie lifetime. SecurityScanner reports the cookie's `Max-Age` or `Expires` attribute on every authentication cookie it detects.

Sensitive paths are URLs that should never be reachable from the public internet: `.env` files, `.git` directories, backup files (`.bak`, `.sql`, `.tar.gz`), admin panels, phpinfo pages, server-status endpoints, and debug routes. SecurityScanner probes a curated list of these paths on every scan.

`.env` files contain database credentials, API keys, and signing secrets. If exposed, an attacker has everything needed to impersonate your services, exfiltrate your database, or forge user sessions. Rotate every secret in the exposed file immediately.

Block the path at the web server level: Nginx `location ~ /\.git { deny all; }`, Apache `<DirectoryMatch "^/.*/\.git/"> Require all denied </DirectoryMatch>`. Most frameworks also serve `.git` if the deployment directory is the web root — move it outside the document root.

Broken Access Control covers any case where a user can act outside their intended permissions: accessing other users' data, escalating to admin, or hitting internal endpoints. Exposed admin panels and sensitive paths are the most common external symptoms.

No — SecurityScanner probes `/admin` and similar paths from the public internet exactly like an attacker would. If you want to keep admin panels off the public internet, put them behind a VPN or zero-trust gateway.

For a typical web server: 80 (HTTP, redirects to HTTPS), 443 (HTTPS). SSH (22) should be on a non-default port or restricted by IP. Database ports (3306, 5432, 27017), Redis (6379), and admin ports (8080, 8443) must never be public. SecurityScanner reports every open port and flags non-essential ones.

Redis without authentication is fully accessible to anyone on the network. Attackers use it to dump data, plant crypto miners, or pivot to other internal services. Bind Redis to 127.0.0.1 or a private network and require AUTH.

Yes. When an open service is detected (SSH, FTP, database, admin panels), SecurityScanner attempts a small list of well-known default credentials. A successful authentication is reported as a critical-severity finding.

The port scan runs in parallel with the other 9 modules and completes in under 60 seconds for the standard port set. It targets the most commonly exploited ports first (database, admin, debug) before sweeping the rest of the IANA registered range.

No — SecurityScanner only sees ports exposed on the public internet. For an internal-network audit, run the scan from inside your network or use a VPN endpoint. The public scan is enough to find firewall misconfigurations and accidental exposure.

A06 covers known vulnerabilities in third-party libraries, frameworks, and runtime dependencies. Even a fully secure codebase is exposed if it ships a vulnerable version of a popular library. SecurityScanner identifies vulnerable JavaScript libraries by hash and version detection.

SecurityScanner fingerprints each JavaScript bundle, extracts library name and version (or hash if the bundle is minified beyond recognition), then cross-references against the CVE database. Findings include CVE ID, severity, and the fixed version.

It depends on exposure. A low-severity CVE in a server-side dependency handling authentication is more urgent than a medium-severity CVE in a build-time tool. SecurityScanner flags every known CVE; prioritize by your actual usage of the vulnerable code path.

Yes. The JS CVE Scan module recognizes the most common bundler output patterns and extracts library versions from filename hashes (webpack chunks), import map entries, and version-locked CDN URLs.

SecurityScanner's CVE database is refreshed against the NVD and major project security advisories. Findings show the database snapshot date so you can assess whether a recent CVE may not yet be reflected in your report.