insecure-defaults

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

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/TECH-HY/SKILLS --skill insecure-defaults-tech-hy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: insecure-defaults
Source: https://github.com/TECH-HY/SKILLS/tree/main/skills/insecure-defaults
Command: npx skills add https://github.com/TECH-HY/SKILLS --skill insecure-defaults-tech-hy

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 configuration is missing. This Skill systematically finds these 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 controls, and exposed debug features across Python, JavaScript, Ruby, and Java codebases. - Verification Workflow: Traces code paths to confirm runtime behavior and production impact before reporting, filtering out test fixtures, example files, and fail-secure crash-on-missing patterns. - Evidence-Based Reporting: Produces structured findings with location, pattern, verification steps, production impact, and exploitation scenarios. - Use Case: Before deploying a web service, run an audit to catch patterns like SECRET = env.get('KEY') or 'default' that would let attackers forge JWTs if the environment variable is missing in production. ## Quick Start Audit this repository for insecure defaults such as hardcoded secret fallbacks, disabled authentication, and weak cryptography, and report each finding with production impact evidence.

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 fallback defaults in my codebase?

Search for patterns like `env.get('KEY') or 'default'`, `process.env.X || 'value'`, and `ENV.fetch(..., default:)` in config, auth, and database directories. Then trace each match to confirm the app runs with the default when the environment variable is missing.

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

Fail-open defaults let the app run insecurely when configuration is missing, such as `SECRET = env.get('KEY') or 'default'`. Fail-secure patterns like `SECRET = env['KEY']` crash the app on startup if the variable is absent, preventing insecure operation.

Should insecure defaults in test files be reported as vulnerabilities?

No. Test fixtures in `test/`, `spec/`, or `__tests__/` directories, example files with `.example` or `.sample` suffixes, and documentation snippets are explicitly out of scope. Only production-reachable code paths should be reported.

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. Skip them when used only for non-security purposes like cache keys or checksums, and prefer bcrypt, Argon2, or AES-GCM.

Why does the audit skip code where the app crashes on missing config?

Crash-on-missing behavior is fail-secure: the application cannot start without proper configuration, so there is no exploitable insecure state. The audit focuses on fail-open patterns where the app silently runs with weak defaults.