C01 Insecure Defaults

What this means

SiteShadow flagged a configuration or "temporary" setting that weakens security (often added for convenience during development) and can accidentally ship to production.

Why it matters

• Attack surface increases silently: debug endpoints, permissive CORS, disabled auth checks.
• Small mistakes become incidents: "just for testing" becomes "in prod for 6 months."
• Compliance risk: insecure defaults are a common root cause in audits and breaches.

Safer examples

1) Make production "secure by default"

DEBUG = False
ALLOW_INSECURE = False

2) Fail closed in config

const allowInsecure = process.env.ALLOW_INSECURE === "true";
if (allowInsecure && process.env.NODE_ENV === "production") {
  throw new Error("ALLOW_INSECURE cannot be enabled in production");
}

3) Tighten common foot-guns

• CORS: don't use * for authenticated APIs.
• Auth: don't keep "skipAuth=true" flags in production code paths.
• Cookies: don't ship without HttpOnly, Secure, and an appropriate SameSite.

How SiteShadow detects it (high level)

• Flags known risky toggles and "temporary bypass" patterns (disableAuth, skipVerify, allowAll, debug=true).
• Looks for settings that differ between dev/prod and warns when prod-safe guards are missing.

References

• OWASP Top 10: https://owasp.org/Top10/

---

← Back to Vulnerability Library