insecure-defaults

Detects fail-open insecure defaults like hardcoded secrets and weak authentication in application code.

507|40|Updated Apr 26, 2026
One-click install
npx skills add https://github.com/waybarrios/opencode-power-pack --skill insecure-defaults-waybarrios
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: insecure-defaults
Source: https://github.com/waybarrios/opencode-power-pack/tree/main/skills/insecure-defaults
Command: npx skills add https://github.com/waybarrios/opencode-power-pack --skill insecure-defaults-waybarrios

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Applications often ship with fail-open defaults—hardcoded secret fallbacks, disabled authentication, permissive CORS, or weak cryptography—that silently run insecurely in production when environment variables are missing. This Skill finds those vulnerabilities and distinguishes them from safe fail-secure patterns. ## Core Features & Use Cases - Fail-Open Detection: Identifies fallback secrets, default credentials, disabled auth, weak crypto (MD5/SHA1/DES/ECB), permissive access, and debug features enabled by default. - Verification Workflow: Traces code paths to confirm whether the app actually runs with the insecure default or crashes safely, reducing false positives. - Scoped Analysis: Skips test fixtures, example files, and documentation to focus on production-reachable code. - Use Case: During a pre-deployment security audit, scan a Node.js codebase and find that process.env.JWT_SECRET || 'default' lets the app start with a known secret, allowing attackers to forge tokens. ## Quick Start Audit this repository for insecure defaults such as hardcoded secret fallbacks, disabled authentication, and weak cryptography, and report each finding with its production impact.

Frequently Asked Questions about insecure-defaults

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find hardcoded secrets and insecure defaults in my code?▼

Search for fallback patterns like env.get('KEY') or 'default', process.env.X || 'value', and ENV.fetch with defaults in config, auth, and database directories. Then trace each match to verify whether the app actually runs with the default or crashes safely without it.

What is the difference between fail-open and fail-secure defaults?▼

Fail-open defaults let the application run insecurely when configuration is missing, such as a hardcoded JWT secret fallback. Fail-secure patterns crash or refuse to start when required configuration is absent, like directly accessing os.environ['SECRET_KEY'] which raises an error.

Which weak cryptography algorithms should be flagged in security audits?▼

Flag MD5, SHA1, DES, RC4, and ECB mode when used for passwords, encryption, tokens, or signature verification. These are acceptable only for non-security purposes like cache keys or checksums, so verify the usage context before reporting.

Should test files and example configs be reported as insecure defaults?▼

No. Skip files in test/, spec/, or __tests__/ directories, files with .example, .template, or .sample suffixes, and documentation examples in README files. Focus only on production-reachable code paths.

Why does my app pass security review but still have insecure defaults?▼

Reviews often miss fallback logic because the production config overrides it, hiding the code-level vulnerability. If the environment variable is ever missing in any deployment, the insecure default activates, so verify the actual runtime behavior with a code trace.