あらゆるスタック向けのセキュリティパターン

Routes without canActivate guards allow unauthorized access to admin panels, user profiles, and sensitive operations.

DomSanitizer.bypassSecurityTrust* methods completely disable XSS protection, enabling script injection when used with any user-controllable data.

Detects Django applications with DEBUG = True in settings. Debug mode exposes sensitive information including settings, environment variables, SQL queries, and stack traces. This must NEVER be enabled in production.

Detects Django SECRET_KEY that is hardcoded, weak, or uses default values. The SECRET_KEY is used for cryptographic signing and must be kept secret and changed in production.

Detects hardcoded secrets in ENV/ARG and piping curl/wget to shell.

Detects user input flowing to template functions that bypass HTML escaping.

Detects user input flowing to os/exec command execution, enabling OS command injection.

API keys, passwords, or tokens hardcoded in source code.

Sensitive fields like password, token, or apiKey included in HTTP responses.

Detects user input flowing to SQL queries without parameterization.

User input passed directly to template.Parse without sanitization.

Detects when internal credentials (API keys, secrets, tokens) are sent in HTTP requests to user-controlled endpoints. This allows attackers to exfiltrate server credentials by providing a malicious webhook URL that captures the sensitive headers or body data. Example vulnerable pattern: ```go // User controls 'endpoint' from request endpoint := r.FormValue("webhook_url") // Server sends its internal API key to attacker-controlled URL req, _ := http.NewRequest("POST", endpoint, nil) req.Header.Set("X-API-Key", os.Getenv("INTERNAL_API_KEY")) client.Do(req) ``` This is different from standard SSRF (which accesses internal resources) - here the attacker exfiltrates server credentials to their own controlled endpoint.

Detects user input flowing to code execution functions like eval() or Function constructor.

Detects user input flowing to shell command execution functions.

Detects security checks (authentication, authorization, validation) that grant access when an error occurs instead of denying it. This is a critical security flaw where the system "fails open" rather than "failing closed/secure". When authentication or authorization checks encounter errors, the system should DENY access by default, not grant it.

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, private keys) Hardcoded real secrets pose security risks: - Exposure in version control - Difficult credential rotation - Accidental disclosure in logs/errors - No dev/prod separation

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.

Detects when user-controlled input is used to access resources belonging to other users at the same privilege level without verifying ownership.

Detects when jwt.decode() output is used for user identity, allowing complete authentication bypass since decode() does not verify signatures.

Detects JWT signing or verification using user-controlled secrets. JWT security relies on keeping the secret key confidential. If an attacker can control or influence the secret used for signing or verification, they can: - Forge valid tokens for any user - Bypass authentication entirely - Impersonate other users This includes: - Using req.body.secret, req.query.secret directly as the JWT secret - Allowing users to provide custom secrets for verification - Using weak or predictable secrets from user input

Detects untrusted user input used in file system operations without proper validation. This can allow attackers to read or write arbitrary files on the server.

Detects when sensitive data fields (passwords, tokens, secrets, API keys) are exposed through API endpoint responses. This commonly happens when: 1. Mapping user data with sensitive fields: `.map(u => ({ password: u.password }))` 2. Returning entire user objects: `res.json(user)` where user has password field 3. Including sensitive fields in response objects: `res.json({ password: user.password })` This is particularly dangerous when AI-generated code returns user collections without filtering sensitive fields, as in debug endpoints or admin panels. Security Impact: - Password hash exposure enabling offline cracking attacks - API key/token leakage allowing account takeover - Session token exposure enabling session hijacking - PII disclosure violating privacy regulations (GDPR, CCPA)

Detects user input flowing into SQL queries without parameterization.

Detects user input flowing to unsafe deserialization functions like node-serialize or yaml.load().

Detects when internal credentials (API keys, secrets, tokens) are sent in HTTP requests to user-controlled endpoints. This allows attackers to exfiltrate server credentials by providing a malicious webhook URL that captures the sensitive headers or body data. Example vulnerable pattern: ```javascript // User controls 'endpoint' from request const endpoint = req.body.webhookUrl; // Server sends its internal API key to attacker-controlled URL await fetch(endpoint, { headers: { 'X-API-Key': process.env.INTERNAL_API_KEY } }); ``` This is different from standard SSRF (which accesses internal resources) - here the attacker exfiltrates server credentials to their own controlled endpoint.