# Use of Hard-coded Credentials (CWE-798) The product contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. **Stack:** JavaScript - Prevalence: 높음 자주 악용됨 - Impact: 치명적 6개의 치명적 심각도 규칙 - Prevention: 문서화됨 11개의 수정 예시 **OWASP:** Identification and Authentication Failures (A07:2021-Identification and Authentication Failures) - #7 ## Description Hard-coded credentials typically create a significant hole that allows an attacker to bypass the authentication that has been configured by the product administrator. This hole might be difficult for the system administrator to detect. ## Prevention 5개의 Shoulder 탐지 규칙을 기반으로 한 Hardcoded Credentials 예방 전략. ### Key Practices - loaded from environment variables or secure secret management systems ### JavaScript Never use hardcoded fallbacks for secrets; fail fast if environment variables are missing Load credentials from environment variables instead of hardcoding in source code Move secrets to environment variables using dotenv or a secret manager ## Warning Signs - [HIGH] Hardcoded secret used as fallback for environment variable. Code: ... If the environment variable is not set, this har - [HIGH] hardcoded secrets used as fallback values for environment variables - [HIGH] Hardcoded credential detected in ... Credentials should never be stored in source code. - [HIGH] hardcoded credentials (passwords, API keys, tokens) in database connections and configuration object - [LOW] Test file contains hard-coded credentials at line ... - [LOW] security anti-patterns in test files that could leak into production - [CRITICAL] Hardcoded ... with high entropy detected: ... - [CRITICAL] hardcoded secrets with high entropy (randomness) that indicate real credentials ## Consequences - 권한 획득 - 보호 메커니즘 우회 ## Mitigations - 자격 증명은 소스 코드 외부에 저장하세요 - 환경 변수나 안전한 자격 증명 저장소를 사용하세요 - 적절한 키 관리 절차를 구현하세요 ## Detection - Total rules: 11 - Critical: 6 - Languages: python, dockerfile, go, javascript, typescript, yaml ## Rules by Language ### Javascript (5 rules) - **Hardcoded Secret in Environment Variable Fallback** [HIGH]: Detects hardcoded secrets used as fallback values for environment variables. Pattern: `process.env.SECRET || 'hardcoded-value'` This is dangerous because: - If the environment variable is not set, the hardcoded value is used - Developers often forget to set env vars in production - The hardcoded fallback may be committed to version control - Creates false sense of security ("we use env vars") This is particularly common with: - JWT secrets - API keys - Database passwords - Encryption keys - Remediation: Remove the fallback and fail fast if the env var is missing: Before (dangerous): const secret = process.env.JWT_SECRET || 'insecure-fallback'; After (safe): const secret = process.env.JWT_SECRET; if (!secret) { throw new Error('JWT_SECRET environment variable is required'); } - **Hardcoded Credentials** [HIGH]: Detects hardcoded credentials (passwords, API keys, tokens) in database connections and configuration objects. Credentials should be loaded from environment variables or secure secret management systems. This is different from CWE-259 (weak password): - CWE-798: Any credential hardcoded in source code (security risk) - CWE-259: Specifically weak/guessable passwords Even a "strong" password is a security risk if hardcoded because: - It gets committed to version control - It's difficult to rotat - Remediation: Move credentials to environment variables: Before: password: 'my-secret-password' After: password: process.env.DB_PASSWORD - **Hardcoded High-Entropy Secrets Detection** [CRITICAL]: Detects hardcoded secrets with high entropy (randomness) that indicate real credentials. This rule uses entropy analysis to avoid false positives from: - Example/placeholder values ("keyboard cat", "your-secret-here") - Test fixtures ("test123", "fake-api-key") - Short/simple strings ("secret", "password") Only flags strings that appear to be REAL secrets: - High entropy (random-looking characters) - Sufficient length (20+ characters for API keys) - Known secret patterns (AWS keys, JWT tokens, - Remediation: Move this secret to environment variables or a secret management service. - **Hardcoded Secrets in Security Operations** [CRITICAL]: Detects hardcoded secrets (API keys, tokens, passwords) flowing into security-sensitive operations. Uses taint analysis to track hardcoded secret strings from their definition to actual usage in authentication, API calls, or cryptographic operations. This approach reduces false positives by only flagging secrets that are actually used, not just defined in comments, examples, or unused variables. - Remediation: Load secrets from environment variables instead of hardcoding: ```javascript require('dotenv').config(); const stripe = require('stripe')(process.env.STRIPE_API_KEY); if (!process.env.STRIPE_API_KEY) { throw new Error('STRIPE_API_KEY environment variable required'); } ``` Learn more: https://shoulder.dev/learn/javascript/cwe-798/hardcoded-secrets - **Security Issues in Test Files** [LOW]: Detects security anti-patterns in test files that could leak into production. While test files don't run in production, they can still pose security risks: 1. **Hard-coded credentials** - Test credentials committed to repos 2. **Real API keys** - Production keys used in tests 3. **Exposed secrets** - Secrets in test fixtures or mocks 4. **Insecure test patterns** - Patterns that might be copy-pasted to production This rule helps maintain test hygiene and prevents credential leaks. - Remediation: Use environment variables or mock data instead of hard-coded credentials. ### Typescript (5 rules) - **Hardcoded Secret in Environment Variable Fallback** [HIGH]: Detects hardcoded secrets used as fallback values for environment variables. Pattern: `process.env.SECRET || 'hardcoded-value'` This is dangerous because: - If the environment variable is not set, the hardcoded value is used - Developers often forget to set env vars in production - The hardcoded fallback may be committed to version control - Creates false sense of security ("we use env vars") This is particularly common with: - JWT secrets - API keys - Database passwords - Encryption keys - Remediation: Remove the fallback and fail fast if the env var is missing: Before (dangerous): const secret = process.env.JWT_SECRET || 'insecure-fallback'; After (safe): const secret = process.env.JWT_SECRET; if (!secret) { throw new Error('JWT_SECRET environment variable is required'); } - **Hardcoded Credentials** [HIGH]: Detects hardcoded credentials (passwords, API keys, tokens) in database connections and configuration objects. Credentials should be loaded from environment variables or secure secret management systems. This is different from CWE-259 (weak password): - CWE-798: Any credential hardcoded in source code (security risk) - CWE-259: Specifically weak/guessable passwords Even a "strong" password is a security risk if hardcoded because: - It gets committed to version control - It's difficult to rotat - Remediation: Move credentials to environment variables: Before: password: 'my-secret-password' After: password: process.env.DB_PASSWORD - **Hardcoded High-Entropy Secrets Detection** [CRITICAL]: Detects hardcoded secrets with high entropy (randomness) that indicate real credentials. This rule uses entropy analysis to avoid false positives from: - Example/placeholder values ("keyboard cat", "your-secret-here") - Test fixtures ("test123", "fake-api-key") - Short/simple strings ("secret", "password") Only flags strings that appear to be REAL secrets: - High entropy (random-looking characters) - Sufficient length (20+ characters for API keys) - Known secret patterns (AWS keys, JWT tokens, - Remediation: Move this secret to environment variables or a secret management service. - **Hardcoded Secrets in Security Operations** [CRITICAL]: Detects hardcoded secrets (API keys, tokens, passwords) flowing into security-sensitive operations. Uses taint analysis to track hardcoded secret strings from their definition to actual usage in authentication, API calls, or cryptographic operations. This approach reduces false positives by only flagging secrets that are actually used, not just defined in comments, examples, or unused variables. - Remediation: Load secrets from environment variables instead of hardcoding: ```javascript require('dotenv').config(); const stripe = require('stripe')(process.env.STRIPE_API_KEY); if (!process.env.STRIPE_API_KEY) { throw new Error('STRIPE_API_KEY environment variable required'); } ``` Learn more: https://shoulder.dev/learn/javascript/cwe-798/hardcoded-secrets - **Security Issues in Test Files** [LOW]: Detects security anti-patterns in test files that could leak into production. While test files don't run in production, they can still pose security risks: 1. **Hard-coded credentials** - Test credentials committed to repos 2. **Real API keys** - Production keys used in tests 3. **Exposed secrets** - Secrets in test fixtures or mocks 4. **Insecure test patterns** - Patterns that might be copy-pasted to production This rule helps maintain test hygiene and prevents credential leaks. - Remediation: Use environment variables or mock data instead of hard-coded credentials.