insecure-defaults

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Insecure Defaults Detection

不安全默认配置检测

Finds fail-open vulnerabilities where apps run insecurely with missing configuration. Distinguishes exploitable defaults from fail-secure patterns that crash safely.

Fail-open (CRITICAL):
```
SECRET = env.get('KEY') or 'default'
```
→ App runs with weak secret
Fail-secure (SAFE):
```
SECRET = env['KEY']
```
→ App crashes if missing

查找应用在缺失配置时不安全运行的**fail-open（故障开放）**漏洞。区分可被利用的默认配置与fail-secure（安全故障）模式——后者会安全崩溃。

fail-open（严重级别：CRITICAL）：
```
SECRET = env.get('KEY') or 'default'
```
→ 应用使用弱密钥运行
fail-secure（安全）：
```
SECRET = env['KEY']
```
→ 缺失配置时应用崩溃

When to Use

适用场景

Security audits of production applications (auth, crypto, API security)
Configuration review of deployment files, IaC templates, Docker configs
Code review of environment variable handling and secrets management
Pre-deployment checks for hardcoded credentials or weak defaults

生产应用的安全审计（认证、加密、API安全）
部署文件、IaC模板、Docker配置的配置审查
环境变量处理与密钥管理的代码审查
硬编码凭证或弱默认配置的部署前检查

When NOT to Use

不适用场景

Do not use this skill for:

Test fixtures explicitly scoped to test environments (files in
```
test/
```
,
```
spec/
```
,
```
__tests__/
```
)
Example/template files (
```
.example
```
,
```
.template
```
,
```
.sample
```
suffixes)
Development-only tools (local Docker Compose for dev, debug scripts)
Documentation examples in README.md or docs/ directories
Build-time configuration that gets replaced during deployment
Crash-on-missing behavior where app won't start without proper config (fail-secure)

When in doubt: trace the code path to determine if the app runs with the default or crashes.

请勿将此技能用于：

明确限定在测试环境的测试夹具（
```
test/
```
、
```
spec/
```
、
```
__tests__/
```
目录下的文件）
示例/模板文件（带有
```
.example
```
、
```
.template
```
、
```
.sample
```
后缀的文件）
仅开发用工具（本地开发用Docker Compose、调试脚本）
README.md或docs/目录中的文档示例
部署期间会被替换的构建时配置
缺失正确配置时无法启动的故障安全行为（fail-secure）

如有疑问：追踪代码路径以确定应用是使用默认配置运行还是崩溃。

Rationalizations to Reject

需驳回的合理化理由

"It's just a development default" → If it reaches production code, it's a finding
"The production config overrides it" → Verify prod config exists; code-level vulnerability remains if not
"This would never run without proper config" → Prove it with code trace; many apps fail silently
"It's behind authentication" → Defense in depth; compromised session still exploits weak defaults
"We'll fix it before release" → Document now; "later" rarely comes

“这只是开发环境默认值” → 如果该代码进入生产环境，即属于问题项
“生产配置会覆盖它” → 需验证生产配置是否存在；若不存在，代码层面的漏洞依然存在
“没有正确配置的话，应用根本不会运行” → 需通过代码追踪证明；许多应用会静默故障
“它在认证机制之后” → 纵深防御原则；会话被攻破后，弱默认配置仍会被利用
“我们会在发布前修复” → 现在就记录下来；“以后”往往不会到来

Workflow

工作流程

Follow this workflow for every potential finding:

对每个潜在问题项遵循以下工作流程：

1. SEARCH: Perform Project Discovery and Find Insecure Defaults

1. 搜索：执行项目发现并查找不安全默认配置

Determine language, framework, and project conventions. Use this information to further discover things like secret storage locations, secret usage patterns, credentialed third-party integrations, cryptography, and any other relevant configuration. Further use information to analyze insecure default configurations.

Example Search for patterns in

**/config/

**/auth/

**/database/

, and env files:

Fallback secrets:

getenv.*\) or ['"]

process\.env\.[A-Z_]+ \|\| ['"]

ENV\.fetch.*default:

Hardcoded credentials:

password.*=.*['"][^'"]{8,}['"]

api[_-]?key.*=.*['"][^'"]+['"]

Weak defaults:
```
DEBUG.*=.*true
```
,
```
AUTH.*=.*false
```
,
```
CORS.*=.*\*
```
Crypto algorithms:
```
MD5|SHA1|DES|RC4|ECB
```
in security contexts

Tailor search approach based on discovery results.

Focus on production-reachable code, not test fixtures or example files.

确定语言、框架和项目约定。利用这些信息进一步发现密钥存储位置、密钥使用模式、带凭证的第三方集成、加密技术及其他相关配置。再结合这些信息分析不安全的默认配置。

示例在

**/config/

、

**/auth/

、

**/database/

目录及环境文件中搜索以下模式：

回退密钥：

getenv.*\) or ['"]

、

process\.env\.[A-Z_]+ \|\| ['"]

、

ENV\.fetch.*default:

硬编码凭证：

password.*=.*['"][^'"]{8,}['"]

、

api[_-]?key.*=.*['"][^'"]+['"]

弱默认配置：
```
DEBUG.*=.*true
```
、
```
AUTH.*=.*false
```
、
```
CORS.*=.*\*
```
加密算法： 安全场景中的
```
MD5|SHA1|DES|RC4|ECB
```

根据发现结果调整搜索方法。

重点关注生产环境可访问的代码，而非测试夹具或示例文件。

2. VERIFY: Actual Behavior

2. 验证：实际行为

For each match, trace the code path to understand runtime behavior.

Questions to answer:

When is this code executed? (Startup vs. runtime)
What happens if a configuration variable is missing?
Is there validation that enforces secure configuration?

对每个匹配项，追踪代码路径以了解运行时行为。

需解答的问题：

此代码何时执行？（启动时vs运行时）
如果配置变量缺失会发生什么？
是否有验证机制强制实施安全配置？

3. CONFIRM: Production Impact

3. 确认：生产环境影响

Determine if this issue reaches production:

If production config provides the variable → Lower severity (but still a code-level vulnerability) If production config missing or uses default → CRITICAL

确定该问题是否会影响生产环境：

如果生产配置提供了该变量 → 降低严重级别（但仍属于代码层面的漏洞）如果生产配置缺失或使用默认值 → 严重级别（CRITICAL）

4. REPORT: with Evidence

4. 报告：附证据

Example report:

Finding: Hardcoded JWT Secret Fallback
Location: src/auth/jwt.ts:15
Pattern: const secret = process.env.JWT_SECRET || 'default';

Verification: App starts without JWT_SECRET; secret used in jwt.sign() at line 42
Production Impact: Dockerfile missing JWT_SECRET
Exploitation: Attacker forges JWTs using 'default', gains unauthorized access

示例报告：

发现问题：硬编码JWT密钥回退
位置：src/auth/jwt.ts:15
模式：const secret = process.env.JWT_SECRET || 'default';

验证：应用在无JWT_SECRET时启动；该密钥在第42行的jwt.sign()中使用
生产环境影响：Dockerfile中缺失JWT_SECRET
利用方式：攻击者使用'default'伪造JWT，获取未授权访问权限

Quick Verification Checklist

快速验证清单

Fallback Secrets:

SECRET = env.get(X) or Y

→ Verify: App starts without env var? Secret used in crypto/auth? → Skip: Test fixtures, example files

Default Credentials: Hardcoded

username

password

pairs → Verify: Active in deployed config? No runtime override? → Skip: Disabled accounts, documentation examples

Fail-Open Security:

AUTH_REQUIRED = env.get(X, 'false')

→ Verify: Default is insecure (false/disabled/permissive)? → Safe: App crashes or default is secure (true/enabled/restricted)

Weak Crypto: MD5/SHA1/DES/RC4/ECB in security contexts → Verify: Used for passwords, encryption, or tokens? → Skip: Checksums, non-security hashing

Permissive Access: CORS

, permissions

, public-by-default → Verify: Default allows unauthorized access? → Skip: Explicitly configured permissiveness with justification

Debug Features: Stack traces, introspection, verbose errors → Verify: Enabled by default? Exposed in responses? → Skip: Logging-only, not user-facing

For detailed examples and counter-examples, see examples.md.

回退密钥：

SECRET = env.get(X) or Y

→ 验证：应用在无环境变量时能否启动？密钥是否用于加密/认证？ → 跳过：测试夹具、示例文件

默认凭证： 硬编码的

username

password

对 → 验证：在部署配置中是否生效？是否无运行时覆盖？ → 跳过：已禁用的账户、文档示例

故障开放型安全设置：

AUTH_REQUIRED = env.get(X, 'false')

→ 验证：默认配置是否不安全（false/禁用/宽松）？ → 安全情况：应用崩溃或默认配置安全（true/启用/受限）

弱加密： 安全场景中的MD5/SHA1/DES/RC4/ECB → 验证：是否用于密码、加密或令牌？ → 跳过：校验和、非安全哈希

宽松访问权限： CORS

、权限

、默认公开 → 验证：默认配置是否允许未授权访问？ → 跳过：有正当理由的显式配置宽松权限

调试功能： 堆栈跟踪、内省、详细错误信息 → 验证：是否默认启用？是否在响应中暴露？ → 跳过：仅日志记录、非用户可见

有关详细示例与反例，请参见examples.md。