Aie Web Security

Web Security Self-Audit (Defensive)

Runs a safe, read-only security review of a website or web app you control. It reviews source code, configuration, dependency manifests, git history, and public response headers. It does not scan, probe, fuzz, or attack anything — this is a self-audit, not a penetration test.

Scope and Safety Rules

• Only audit assets the user owns or is explicitly authorized to review.
• Read-only. Do not send crafted/malicious payloads, brute-force, or exploit anything.
• Never print full secret values in output — mask them (re_****…abcd).
• If asked to attack a third-party site or bypass a control, decline and redirect to the defensive scope.

Workflow

1. Confirm scope — which repo/folder, which deployed URL (if any), and the stack (framework, host, package manager). Stay stack-agnostic; adapt commands to what you find.
2. Run the checks in the order below, gathering evidence.
3. Report using the severity format at the end.

Read reference/audit-checklist.md for the full itemized checklist across all areas. Read reference/security-headers.md for header values and host-specific config examples. Read reference/glossary.md if the user needs plain-language definitions.

Check Areas (summary)

1. Secrets exposure (Critical) — Grep the working tree AND git history for API keys, tokens, passwords, private keys, connection strings. Confirm .env* and *.pem are git-ignored and not committed. Confirm secrets live in the host's environment-variable store, not in client-shipped bundles. Any secret prefixed for client exposure (e.g., build-time public vars) must NOT be a real secret. If a live secret is found, flag it Critical and instruct immediate rotation.
2. Dependencies — Run the package manager's audit (npm audit, pnpm audit, yarn audit, pip-audit, etc.). Classify by severity, note fixable vs. breaking.
3. Security headers — Check for Content-Security-Policy, Strict-Transport-Security (HSTS), X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors), Referrer-Policy, and Permissions-Policy. See reference/security-headers.md.
4. HTTPS / TLS — Certificate validity, single 301 HTTP→HTTPS redirect, HSTS present, no mixed content (HTTP assets on an HTTPS page).
5. Input handling / XSS — Flag innerHTML, dangerouslySetInnerHTML, document.write, and unescaped user input rendered to the DOM or into URLs. Recommend textContent and encodeURIComponent.
6. CSRF / cookies — Confirm state-changing endpoints validate origin or use anti-CSRF tokens; confirm cookies set SameSite and, for sensitive cookies, HttpOnly + Secure.
7. CORS — Flag wildcard Access-Control-Allow-Origin: * on any authenticated or sensitive endpoint.
8. Third-party scripts — Inventory external scripts; recommend Subresource Integrity (SRI) and version pinning for CDN resources; note what data analytics/trackers collect.
9. Abuse prevention — Confirm public form/serverless endpoints have spam protection (honeypot and/or rate limiting) and reasonable function timeouts.
10. Privacy compliance — Confirm a linked privacy policy, disclosure of data collected and third parties used, cookie consent where required, and a contact path for data requests (GDPR/CCPA baseline).

Output Format

Lead with an overall grade and counts, then list findings.

Overall: B — 1 critical, 3 warnings, 4 recommendations

For each finding:

• Severity — CRITICAL (fix before launch) / WARNING (fix within a week) / RECOMMENDATION (best practice)
• What — the issue, with file path and line or the header that's missing
• Why it matters — one plain-language sentence
• Fix — exact code, config, or step

Order findings Critical → Warning → Recommendation.

References

• OWASP Top 10 — https://owasp.org/www-project-top-ten/
• OWASP Secure Headers Project — https://owasp.org/www-project-secure-headers/
• MDN HTTP headers — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• MDN Content Security Policy — https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
• MDN Mixed content — https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content