Jede von Seaworthy ausgeführte Prüfung erklärt. Klicken Sie auf eine Prüfung, um zu sehen, was sie findet, warum das wichtig ist und wie Sie es beheben.
id: security.hardcoded-secrets🔗
API keys, tokens, passwords, connection strings in source
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Move this value to an environment variable and reference it via process.env.
id: security.auth-missing-endpoints🔗
Route handler lacks authentication middleware, leaving endpoints unprotected.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Apply authentication middleware to this route handler. Use requireAuth, passport, JWT verification, or session-based auth.
id: security.sql-injection-surface🔗
Raw string concatenation in SQL queries
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Use parameterised queries or an ORM instead of string interpolation. Never concatenate user input into SQL strings.
id: security.os-command-injection🔗
Detects OS command execution with potentially unsafe arguments
Unsafe execution of dynamic strings as code or shell commands can lead to arbitrary code execution, letting attackers take complete control of the host machine (CWE-94).
Avoid shell execution with interpolated strings. Use parameterised APIs (e.g. execFile with args array, subprocess.run with list args).
id: security.file-inclusion🔗
Detects include/require with user-controlled or dynamic paths
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Avoid dynamic include/require paths from user input. Use an allow-list of permitted files and resolve paths against a trusted base directory.
id: security.unsafe-deserialization🔗
Detects deserialization of untrusted data with pickle, yaml.load, or marshal
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Never deserialize untrusted data. Use yaml.safe_load, JSON, or signed formats. Avoid pickle and marshal on external input.
id: security.hardcoded-passwords🔗
Detects password values assigned directly in source code
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Store passwords in environment variables or a secrets manager. Never commit credentials to source code.
id: security.html-css-comments-secrets🔗
Hardcoded secrets inside HTML or CSS comments and commented JSON/config snippets
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Remove secrets from comments and sample config blocks. Move credentials to runtime environment variables or a secure secret manager.
id: security.committed-env🔗
A .env file is tracked by Git, exposing configuration and potential secrets in version history.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add .env to .gitignore. If the file is already tracked, use git rm --cached to untrack it without deleting, or rotate any exposed secrets.
id: security.cors-too-permissive🔗
CORS configuration uses a wildcard origin, allowing requests from any domain.
Weak HTTP headers, CORS policies, or referrer configurations expose the site to clickjacking, data exfiltration, and sensitive data leakage to third parties.
Restrict Access-Control-Allow-Origin to your specific frontend domains rather than using a wildcard.
id: security.sensitive-data-in-logs🔗
Logging statements may leak sensitive data such as credentials or PII.
Improper logging and monitoring configurations can expose sensitive debugging details to attackers or fail to provide alert visibility during active service outages.
Redact sensitive fields before logging. Use a logging library with automatic PII scrubbing or log only non-sensitive summary data.
id: security.xss-surface🔗
Detects XSS-prone APIs such as innerHTML and document.write()
Cross-site scripting (XSS) allows attackers to inject malicious client-side scripts. This can lead to session hijacking, cookie theft, or unauthorized actions on behalf of users (CWE-79).
Use textContent, React children, or a sanitization library like DOMPurify instead of innerHTML or document.write().
id: security.shell-arbitrary-evaluation🔗
Shell eval or source command uses an unquoted dynamic argument.
Unsafe execution of dynamic strings as code or shell commands can lead to arbitrary code execution, letting attackers take complete control of the host machine (CWE-94).
Avoid eval and source for dynamic input. If a shell command is required, validate against an allow-list and pass quoted, fixed arguments.
id: security.shell-unescaped-path-deletion🔗
rm command uses an unquoted variable path that may expand unexpectedly.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Quote shell path variables and validate them before deletion. Prefer rm -rf -- "$TARGET_DIR" after checking the path is non-empty and under an expected base directory.
id: security.open-redirect🔗
Detects redirects that may use user-controlled URLs
Unvalidated redirects allow attackers to redirect users to malicious websites, facilitating phishing campaigns and social engineering attacks.
Validate redirect targets against an allow-list of trusted domains. Never pass raw user input into Location headers.
id: security.unsafe-file-upload🔗
Detects file uploads that use user-controlled destination paths
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Validate file type and extension server-side, generate random filenames, and store uploads outside the web root.
id: security.html-inline-unsafe-script🔗
Inline HTML scripts and event handlers should not perform unsafe DOM writes or execute dynamic code
Cross-site scripting (XSS) allows attackers to inject malicious client-side scripts. This can lead to session hijacking, cookie theft, or unauthorized actions on behalf of users (CWE-79).
Replace unsafe inline DOM writes and dynamic code with safe DOM APIs, escaped text nodes, and validated event handling.
id: security.weak-key-entropy🔗
Detects low-entropy random generation (under 16 bytes / 128 bits) used for keys, tokens, or identifiers
Low-entropy keys or tokens can be predicted or brute-forced by attackers, leading to bypass of authentication or cryptographic controls (CWE-326).
Use at least randomBytes(16) (128 bits) for keys, tokens, and identifiers. For license keys, prefer randomBytes(16) or crypto.getRandomValues() with 16+ bytes.
id: security.insecure-api-url-default🔗
Detects HTTP (non-HTTPS) default URLs for API endpoints in configuration code
Using cleartext HTTP defaults for API endpoints exposes communication to man-in-the-middle (MITM) attacks, potentially leaking sensitive data or allowing traffic interception (CWE-319).
Default all API URLs to HTTPS. Override via environment variable if needed for local development, but never default to cleartext HTTP for production endpoints.
id: security.taint-command-injection🔗
User-controlled data flows to a command execution sink without sanitisation.
Command injection lets attackers execute arbitrary operating-system commands on your server. This can lead to full server compromise, data exfiltration, or ransomware deployment (CWE-78).
Avoid shell execution with interpolated strings. Use parameterised APIs (e.g. execFile with args array).
id: security.taint-path-traversal🔗
User-controlled data flows to a filesystem sink without path validation.
Path traversal allows attackers to read or write files outside the intended directory, potentially exposing source code, configuration files, or secrets (CWE-22).
Resolve paths against a trusted base directory, reject parent-segment sequences, and avoid passing raw user strings into fs APIs.
id: security.xxe-surface🔗
XML parser invoked with external entity expansion enabled (e.g. libxml noent: true), enabling XXE attacks.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Disable external entity expansion in the XML parser. Use a library that is XXE-safe by default.
id: security.permissive-grants🔗
Granting extensive privileges (like GRANT ALL) to public or anonymous roles is insecure.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Restrict privileges by granting only necessary permissions (e.g. SELECT, INSERT) to specific, authorized roles rather than PUBLIC or anonymous roles.
id: security.sql-rls-static🔗
PostgreSQL tables containing private tenant data must enable and enforce Row-Level Security (RLS).
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Enable Row-Level Security via ALTER TABLE ... ENABLE ROW LEVEL SECURITY and FORCE ROW LEVEL SECURITY, and define restrictive policies with user boundary checks.
id: security.sql-security-definer-search-path🔗
Functions defined as SECURITY DEFINER execute with privileges of the owner and must lock the search_path to prevent hijacking.
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Add an explicit "SET search_path = public" or trusted schema when creating SECURITY DEFINER functions to lock execution context.
id: security.sql-missing-rls🔗
PostgreSQL tables containing private tenant data must enable and enforce Row-Level Security (RLS).
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Define a policy with CREATE POLICY ... ON ... USING (...) to restrict data access to authorized users.
id: security.jwt-alg-none🔗
JWT verification does not restrict algorithms, allowing forged unsigned tokens via the "none" algorithm
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Always pass an explicit algorithms allowlist to jwt.verify() (e.g. { algorithms: ["HS256"] }). Never accept "none" as a valid algorithm.
id: security.refresh-token-in-localstorage🔗
Refresh tokens or long-lived credentials stored in localStorage are vulnerable to theft via XSS
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Store refresh tokens in httpOnly, Secure, SameSite=Strict cookies — not localStorage or sessionStorage. XSS cannot read httpOnly cookies.
id: security.path-traversal🔗
File path constructed by concatenating user input, enabling directory traversal attacks.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Resolve and validate file paths against a base directory. Reject paths containing ../ or absolute paths from user input.
id: security.unsafe-innerhtml🔗
Assignment to innerHTML can lead to XSS if user input is included.
Cross-site scripting (XSS) allows attackers to inject malicious client-side scripts. This can lead to session hijacking, cookie theft, or unauthorized actions on behalf of users (CWE-79).
Use textContent or sanitize HTML before assigning to innerHTML. Use a library like DOMPurify.
id: security.untrusted-deserialization🔗
Deserialization of user-controlled data without validation, enabling code execution attacks.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Validate and sanitise deserialized data. Prefer safe parsers with type schemas. Avoid pickle.loads on untrusted input.
id: security.xxe-parsing🔗
XML parser called without disabling external entity expansion, enabling XXE attacks.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Disable external entity expansion in the XML parser. Use a library that is XXE-safe by default.
id: security.dangerous-eval🔗
Detects dangerous dynamic code execution such as eval(), exec(), and new Function()
Unsafe execution of dynamic strings as code or shell commands can lead to arbitrary code execution, letting attackers take complete control of the host machine (CWE-94).
Avoid eval(), exec(), and new Function(). Use safer alternatives like JSON.parse for data parsing, or refactor to eliminate dynamic code execution.
id: security.html-missing-csp🔗
Full HTML pages should include a robust Content Security Policy or receive one from static-host headers
Weak HTTP headers, CORS policies, or referrer configurations expose the site to clickjacking, data exfiltration, and sensitive data leakage to third parties.
Add a strong Content Security Policy via the HTML head or static-host headers. Avoid unsafe wildcards and inline execution where possible.
id: security.html-static-host-headers🔗
Static site host config should supply route-wide security headers for browser pages
Weak HTTP headers, CORS policies, or referrer configurations expose the site to clickjacking, data exfiltration, and sensitive data leakage to third parties.
Configure route-wide security headers in the static host config, including CSP, Referrer-Policy, X-Content-Type-Options, frame protection, and Permissions-Policy.
id: security.html-referrer-leak🔗
target="_blank" anchors or forms without rel protection can leak the referrer and enable tabnabbing
Weak HTTP headers, CORS policies, or referrer configurations expose the site to clickjacking, data exfiltration, and sensitive data leakage to third parties.
Add rel="noopener noreferrer" to target="_blank" anchors and forms. Avoid opening untrusted destinations in a new tab without rel protection.
id: security.css-insecure-import🔗
External CSS imports or URL loads over HTTP can leak content and enable network interception
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Load CSS and fonts over HTTPS only. Remove cleartext HTTP imports and URL loads from stylesheets.
id: security.html-mixed-content🔗
Page resources or embedded styles load over unencrypted HTTP instead of HTTPS
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Upgrade all embedded resource URLs to HTTPS. Avoid loading page assets or embedded styles over cleartext HTTP.
id: security.html-external-asset-integrity🔗
Third-party scripts and stylesheets should include subresource integrity and compatible crossorigin attributes
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add integrity and crossorigin to third-party scripts and stylesheets, or self-host the asset.
id: security.html-insecure-form-action🔗
Forms submitting over cleartext or scheme-relative URLs can leak user input and bypass transport security
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Submit forms over HTTPS or to a same-origin relative endpoint. Avoid cleartext HTTP and scheme-relative action URLs for sensitive submissions.
id: security.html-iframe-sandbox🔗
External iframes should use restrictive sandboxing to limit script and origin access
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add a restrictive sandbox attribute to third-party iframes. Avoid combining allow-scripts and allow-same-origin unless the content is fully trusted.
id: security.html-unsafe-embed🔗
External object and embed elements should not load active plugin content without tight type restrictions
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Prefer sandboxed iframes or self-hosted assets. Avoid loading third-party plugin content with object or embed, and restrict MIME types to safe passive content where possible.
id: security.html-meta-redirect🔗
Short-delay meta refresh redirects can be used for phishing, open redirects, or policy bypasses
Unvalidated redirects allow attackers to redirect users to malicious websites, facilitating phishing campaigns and social engineering attacks.
Replace meta refresh redirects with server-side redirects or validated client navigation. Avoid short-delay refreshes that point to external URLs or internal paths.
id: security.html-base-tag-hijack🔗
External or mispositioned base tags can rewrite relative URLs and alter page navigation
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Remove external base tags or place a same-origin base URL inside <head>. Avoid base target="_blank" on untrusted pages.
id: security.html-import-map-integrity🔗
Import maps should not redirect module specifiers to external origins without trust controls
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Keep import map entries on same-origin or relative URLs. Avoid mapping module specifiers to external CDNs unless you can trust and verify the source.
id: security.css-data-exfiltration🔗
Attribute selectors combined with external HTTP URLs can exfiltrate sensitive values from forms
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Remove attribute-selector rules that fetch external URLs. Keep sensitive form value matching and URL loads out of untrusted CSS.
id: security.css-external-font-integrity🔗
External CDN fonts loaded from @font-face can be supply-chain risks when self-hosting is not used
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Self-host font files or use a trusted local font source. Avoid loading fonts from public CDNs in production stylesheets.
id: security.insecure-random🔗
Detects use of non-cryptographic random in security-sensitive contexts
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use a cryptographically secure random generator (e.g. crypto.getRandomValues() in JS, secrets module in Python, SecureRandom in Java, crypto/rand in Go).
id: security.dynamic-sql-columns🔗
Detects template literal or string interpolation used to build SQL column names, which can allow injection if values come from user input
Interpolating dynamic column names in SQL queries bypasses parameterized query protection, introducing SQL injection risks where attackers can manipulate database structures (CWE-89).
Use a whitelist mapping from input keys to allowed column names. Never interpolate user-supplied strings into SQL column positions.
id: security.weak-email-validation🔗
Detects overly permissive email validation regexes that accept invalid or unsafe inputs
Overly permissive email validation patterns allow malformed, spoofed, or malicious inputs to bypass business rules, leading to account validation issues or data corruption (CWE-20).
Use a stricter regex pattern (e.g. RFC 5322 subset) or a dedicated email validation library (e.g. Zod .email(), validator.js isEmail). At minimum, require a domain with a TLD of 2+ characters.
id: security.idempotency-key-leak🔗
Detects idempotency keys containing structured identifiers (subscription IDs, license IDs) that leak business data to external providers
Embedding structured internal identifiers in idempotency keys leaks business-sensitive data (such as subscription or license IDs) to payment providers or third-party log systems (CWE-200).
Generate idempotency keys using randomUUID() or an HMAC derived from the operation key. Never embed subscription IDs, license IDs, or other business identifiers that external providers could log.
id: security.taint-xss🔗
User-controlled data flows to an XSS sink without sanitisation.
An attacker who can control data sent to an XSS sink can inject malicious scripts that execute in victims' browsers. This can lead to session hijacking, credential theft, or defacement.
Sanitise user input before rendering. Use encodeURIComponent for URLs, or a library like DOMPurify for HTML.
id: security.taint-sql-injection🔗
User-controlled data flows to a SQL query sink without parameterisation.
SQL injection allows attackers to read, modify, or delete database records. It is consistently one of the most common and damaging web vulnerabilities (CWE-89).
Use parameterised queries or an ORM. Never concatenate user input into SQL strings.
id: security.taint-open-redirect🔗
User-controlled data flows to a redirect sink without URL validation.
Unvalidated redirects allow attackers to redirect users to malicious websites, facilitating phishing campaigns and social engineering attacks.
Validate redirect targets against an allow-list of trusted domains. Never pass raw user input into redirect helpers or Location headers.
id: security.taint-prototype-pollution🔗
User-controlled data flows to an object merge or assignment sink without sanitisation.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Validate and block __proto__, constructor, and prototype keys before merging objects. Use Object.create(null) for dictionaries.
id: security.taint-code-execution🔗
User-controlled data flows to a dynamic code execution sink without sanitisation.
Unsafe execution of dynamic strings as code or shell commands can lead to arbitrary code execution, letting attackers take complete control of the host machine (CWE-94).
Avoid eval(), exec(), and new Function() with user input. Use safer alternatives like JSON.parse for data parsing.
id: security.missing-csrf-protection🔗
State-changing route handler without visible CSRF token verification.
Cross-Site Request Forgery (CSRF) allows malicious sites to perform actions on behalf of authenticated users without their consent, potentially leading to unauthorized state modifications.
Add CSRF token verification to all state-changing endpoints. Use a CSRF middleware for your framework.
id: security.weak-session-id🔗
Session identifier derived from user-controlled or predictable input.
Weak session identifiers or insecure cookies can be intercepted or predicted by attackers, leading to session hijacking and unauthorized account access.
Generate session identifiers server-side with a cryptographically secure random source. Never accept client-supplied session IDs.
id: security.rails-mass-assignment🔗
Active Record model created or updated with raw params hash, bypassing strong parameters.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use strong parameters with params.require(:model).permit(:attr1, :attr2) to whitelist allowed attributes.
id: security.rails-insecure-session-config🔗
Session cookie is missing secure flags (secure, httponly, same_site).
Weak session identifiers or insecure cookies can be intercepted or predicted by attackers, leading to session hijacking and unauthorized account access.
Set secure: true, httponly: true, and same_site: :strict on session cookies in config/initializers/session_store.rb.
id: security.rust-unsafe-blocks🔗
Usage of unsafe blocks without a preceding safety documentation comment.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Document every unsafe block with a preceding "// SAFETY: <explanation>" comment explaining why the invariants are satisfied.
id: security.missing-security-headers🔗
Application does not set HTTP security response headers (HSTS, X-Content-Type-Options, X-Frame-Options, Permissions-Policy)
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Add helmet() (Node.js) or equivalent security-header middleware. At minimum set Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options, and Permissions-Policy.
id: security.gh-actions-unpinned🔗
GitHub Actions workflow steps reference third-party actions by mutable tag rather than a full commit SHA
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Pin every third-party action to a full 40-character commit SHA, e.g. uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683. Use a tool like Renovate or pin-github-action to automate this.
id: security.graphql-introspection-prod🔗
GraphQL server exposes introspection without disabling it for production environments
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Disable GraphQL introspection in production: set introspection: process.env.NODE_ENV !== "production" in Apollo Server, or use a validationRules plugin that blocks introspection queries.
id: security.graphql-no-depth-limit🔗
GraphQL server has no query depth or complexity limiting, enabling denial-of-service via deeply nested queries
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Add query depth limiting with graphql-depth-limit or complexity analysis with graphql-query-complexity. Wire the validation rule into ApolloServer validationRules or the equivalent for your framework.
id: security.jwt-no-expiry🔗
JWT tokens are signed without an expiry claim (exp / expiresIn), making them valid indefinitely
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Set a short expiry on all issued JWTs using expiresIn (jsonwebtoken), .setExpirationTime() (jose), or an "exp" claim in the payload (PyJWT). Use refresh tokens to extend sessions.
id: security.broken-crypto-algorithm🔗
Use of a deprecated or broken encryption algorithm such as DES or RC4.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use AES-256-GCM or ChaCha20-Poly1305. Never use DES, RC4, or ECB mode.
id: security.http-method-override🔗
methodOverride middleware enabled, allowing clients to override HTTP methods via query parameters or headers.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Disable methodOverride or restrict it to trusted clients. Prefer standard HTTP methods.
id: security.http-no-tls🔗
Hardcoded HTTP URL that should use HTTPS for transport security.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use HTTPS URLs. Configure HSTS and redirect HTTP to HTTPS at the server level.
id: security.weak-encryption-mode🔗
Use of a raw cipher initialisation that may lack authentication (AEAD).
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use authenticated encryption (AES-256-GCM, ChaCha20-Poly1305). Avoid raw CBC/CTR without a MAC.
id: security.weak-hash-algorithm🔗
Use of a cryptographically weak hash function such as MD5 or SHA1.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use SHA-256 or stronger. For password hashing use bcrypt, scrypt, or Argon2.
id: security.no-document-write🔗
Detects the use of document.write which can lead to XSS vulnerabilities
Cross-site scripting (XSS) allows attackers to inject malicious client-side scripts. This can lead to session hijacking, cookie theft, or unauthorized actions on behalf of users (CWE-79).
Avoid document.write(). Use DOM APIs like appendChild(), innerHTML with sanitization, or a templating system instead.
id: security.html-javascript-uri🔗
javascript: URLs execute code directly from HTML attributes and can enable XSS-style execution
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Replace javascript: URLs with normal links or buttons and event handlers. Avoid direct script execution in HTML attributes.
id: security.gh-actions-excessive-permissions🔗
GitHub Actions workflow grants overly broad or undeclared default permissions
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Add a top-level "permissions: {}" block and grant only the minimum scopes needed per job, e.g. "permissions: { contents: read }".
id: resilience.no-input-validation🔗
User input is not validated before processing, increasing risk of injection and data corruption.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Validate user input with a schema library like zod, joi, or yup. Set request size limits on your HTTP server.
id: resilience.missing-error-handling🔗
Async operations lack error handling, which may cause unhandled rejections or crashes.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add try/catch blocks around async operations. Ensure all promises have .catch() handlers or are inside an async function with error handling.
id: resilience.swallowed-catch🔗
Empty catch blocks swallow errors without handling
Swallowed errors hide bugs, make debugging impossible in production, and can mask security incidents such as failed authentication attempts or database corruption (CWE-391).
Add proper error handling in catch blocks. Log errors, re-throw when appropriate, or handle the specific error case.
id: resilience.destructive-sql-migration🔗
Destructive operations like DROP TABLE, DROP COLUMN, or TRUNCATE pose high risk of data loss.
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Verify that this destructive change is intended and has safe rollback/data preservation procedures in place.
id: resilience.sql-broad-mutation🔗
UPDATE or DELETE statements without a WHERE clause (or with a tautology like WHERE true) mutate the entire table.
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Specify a restrictive WHERE clause on the UPDATE or DELETE statement to target only intended rows.
id: resilience.rust-handler-panics🔗
Use of panicking methods like unwrap or expect inside asynchronous routing handlers.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Avoid calling unwrap(), expect(), or panic!() inside async routing handlers. Propagate errors using the "?" operator, or return a Result with a proper error response.
id: resilience.no-rate-limiting🔗
Public API endpoints lack rate limiting, making them vulnerable to abuse and DoS attacks.
Without resource limits, timeouts, or circuit breakers, failures in external dependencies or traffic spikes can consume system threads and exhaust resources, causing outages.
Add rate-limiting middleware to public routes. Use express-rate-limit, rate-limiter-flexible, or a gateway-level limiter.
id: resilience.no-pagination🔗
List endpoints return unlimited results without pagination, risking performance degradation.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add LIMIT and OFFSET (or .limit() / .skip() in your ORM) to list queries. Use cursor-based pagination for large datasets.
id: resilience.missing-timeout🔗
HTTP requests or database queries lack timeouts, potentially causing indefinite hangs.
Without resource limits, timeouts, or circuit breakers, failures in external dependencies or traffic spikes can consume system threads and exhaust resources, causing outages.
Add a timeout to this HTTP call. Use AbortSignal.timeout() for fetch, or the timeout option for axios.
id: resilience.no-retry-logic🔗
External service calls lack retry logic, reducing resilience to transient failures.
Without resource limits, timeouts, or circuit breakers, failures in external dependencies or traffic spikes can consume system threads and exhaust resources, causing outages.
Wrap external calls with retry logic using p-retry, async-retry, or implement exponential backoff manually.
id: resilience.webhook-processing-defects🔗
Checks webhook handlers for missing signature checks, missing idempotency, out-of-order delivery race conditions, and lack of reconciliation fallbacks.
Relying on payments provider webhooks without verifying signatures leads to security bypasses, while missing idempotency, sequence checks, or active sync checks causes out-of-sync subscriptions and payment processing loops.
Validate headers using webhook signature secrets, log and check event IDs in a persistent cache or database, compare events occurred_at timestamps, and implement a cron fallback or check-on-access reconciliation mechanism to query the payments provider API.
id: resilience.html-inline-resilience🔗
Inline script blocks should handle network failures explicitly and avoid infinite retries or swallowed errors
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add timeout, retry, and explicit error handling to inline fetch/XHR logic. Avoid empty catch blocks and infinite retry loops in page scripts.
id: resilience.no-backoff-jitter🔗
Retry loops without jitter cause thundering herd
Without jitter, all retries from multiple clients can align and overwhelm a recovering service, causing cascading failures (CWE-770).
Add exponential backoff with jitter to retry logic. Use a library like p-retry or implement jitter with Math.random().
id: resilience.no-circuit-breaker🔗
Missing circuit breaker around external calls
Without a circuit breaker, a failing downstream service can tie up all your connections and threads, causing your own service to fail (CWE-1042).
Add a circuit breaker around external service calls. Use a library like opossum or implement a simple state machine.
id: resilience.infinite-retry🔗
Retry loops without max-attempts
Infinite retries can exhaust memory, CPU, and network resources. They also delay failure detection, making incident response harder (CWE-834).
Add a maximum attempt counter to retry loops. Use a for loop with a fixed limit or a while loop with a counter and break condition.
id: resilience.missing-transaction-guard🔗
Large migrations with multiple data mutations should run inside a transaction to prevent partial applications and state corruption.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Wrap the entire migration script inside a transaction using BEGIN; and COMMIT; statements.
id: resilience.orm-n-plus-one🔗
ORM results are iterated with a per-row database query instead of a single batch load
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Replace per-row queries inside loops with a single batch query using include/eager loading (Prisma include, Sequelize eager loading, SQLAlchemy joinedload, ActiveRecord includes).
id: resilience.missing-memory-limit🔗
Buffer.alloc used without a maximum size check for user-controlled sizes.
Without resource limits, timeouts, or circuit breakers, failures in external dependencies or traffic spikes can consume system threads and exhaust resources, causing outages.
Enforce a maximum allocation size before calling Buffer.alloc. Reject user-controlled sizes above a safe threshold.
id: resilience.missing-timeout-config🔗
HTTP client call without an explicit timeout configuration.
Without resource limits, timeouts, or circuit breakers, failures in external dependencies or traffic spikes can consume system threads and exhaust resources, causing outages.
Add a timeout to HTTP requests. Use AbortSignal.timeout() for fetch or the timeout option for axios.
id: ops.dockerfile-secrets-in-env🔗
Dockerfile bakes secrets or credentials into image layers via ENV or ARG instructions
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Never pass secrets via ENV or ARG — they persist in image history. Use Docker BuildKit secrets (RUN --mount=type=secret), environment variables injected at container start, or a secrets manager.
id: ops.no-version-control🔗
No Git repository detected. Version control is essential for collaboration and code recovery.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Initialize a Git repository with git init and commit your code. Regular commits provide history, collaboration, and a safety net for recovery.
id: ops.no-graceful-shutdown🔗
Server lacks graceful shutdown handling, risking dropped requests and data loss on restart.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Listen for SIGTERM and SIGINT signals. Gracefully close server connections and drain in-flight requests before exiting.
id: ops.missing-observability🔗
No metrics, tracing, or structured telemetry hooks
Without observability, you cannot detect outages, debug performance regressions, or measure the impact of deployments. Incidents become blind hunts (CWE-778).
Add metrics, tracing, or structured logging to your service. Use libraries like prom-client, dd-trace, or OpenTelemetry to emit observable telemetry.
id: ops.secret-rotation-friction🔗
Hardcoded secret paths impeding automated rotation
When secrets are hardcoded, rotating them requires a code change, review, build, and deployment. This friction leads to long-lived secrets and increases blast radius if a credential is leaked (CWE-798).
Load secrets from a secret manager (e.g., AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) instead of hardcoding them. This enables automated rotation without redeploying code.
id: ops.env-drift🔗
.env.example is out of sync with runtime environment variable usage
Drift between `.env.example` and runtime usage causes deployment failures, hidden misconfigurations, and secret sprawl. New developers may miss required variables (CWE-1188).
Keep .env.example in sync with the variables your code reads at runtime. Add a CI check or lint rule that flags missing or unused environment variables.
id: ops.dockerfile-runs-as-root🔗
Container image has no non-root USER directive — all processes run as root
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Create a non-root user and switch to it before CMD/ENTRYPOINT: RUN addgroup -S app && adduser -S app -G app followed by USER app.
id: ops.debug-mode-enabled🔗
Debug / verbose logging enabled in production config or source code
Improper logging and monitoring configurations can expose sensitive debugging details to attackers or fail to provide alert visibility during active service outages.
Disable debug logging and verbose mode in production. Use environment-specific config files or flags.
id: ops.hardcoded-localhost🔗
localhost URL is hardcoded rather than configured via environment variables.
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Replace localhost with a configurable base URL. Use environment variables or a config module.
id: ops.no-health-check🔗
No health check endpoint is defined, making it harder to monitor service availability.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Add a /health or /healthz endpoint that returns a 200 status when your service is operational.
id: ops.missing-structured-logging🔗
Logging uses unstructured format, making log analysis and monitoring more difficult.
Improper logging and monitoring configurations can expose sensitive debugging details to attackers or fail to provide alert visibility during active service outages.
Use a structured logging library like pino or winston with JSON output for machine-readable logs.
id: ops.dockerfile-no-healthcheck🔗
Dockerfile has no HEALTHCHECK instruction — container orchestrators cannot detect unhealthy state
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Add a HEALTHCHECK instruction, e.g.: HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1
id: ops.missing-dockerignore🔗
Dockerfile is present without a .dockerignore — build context may include node_modules, .env files, or other sensitive data
Demnächst - wir schreiben detaillierte Erklärungen für jede Prüfung.
Add a .dockerignore file listing directories and files to exclude from the build context: node_modules, .env, .git, *.log, dist, coverage.
id: ops.hardcoded-port🔗
Server port number hardcoded rather than configured via environment variables.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use process.env.PORT with a fallback value. Never hardcode port numbers in source.
id: ops.insecure-file-permissions🔗
fs.chmod call that may set overly permissive file permissions.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Use the most restrictive file permissions possible. Prefer 0o600 for secrets, 0o644 for config.
id: dependencies.missing-lockfile🔗
No lockfile found. Unpinned dependencies are a reproducibility and supply-chain risk.
Unpinned dependency versions make builds non-deterministic and expose the application to unexpected breaking updates or supply-chain attacks.
Commit a lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml, Gemfile.lock, go.sum, composer.lock) or Maven/Gradle reproducibility artifacts (mvnw, gradle.lockfile) to pin exact dependency versions.
id: dependencies.known-cves🔗
Dependencies have known security vulnerabilities with published CVEs.
Dependencies with known CVEs introduce documented vulnerabilities that attackers can exploit to compromise the application. Keeping packages updated is a core security baseline.
Run npm audit fix or upgrade the affected dependency to a patched version.
id: dependencies.html-cdn-vulnerable-versions🔗
CDN-loaded scripts and stylesheets can expose known-vulnerable library versions
Dependencies with known CVEs introduce documented vulnerabilities that attackers can exploit to compromise the application. Keeping packages updated is a core security baseline.
Upgrade the CDN asset to a patched version or self-host the library with a pinned release and integrity controls.
id: dependencies.cargo-known-cves🔗
Cargo.lock dependencies have known security advisories from the RustSec database.
Dependencies with known CVEs introduce documented vulnerabilities that attackers can exploit to compromise the application. Keeping packages updated is a core security baseline.
Run `cargo update` to upgrade to a patched version. Check the RustSec advisory for migration guidance.
id: dependencies.bundler-known-cves🔗
Gemfile.lock dependencies have known security advisories from the Ruby advisory database.
Dependencies with known CVEs introduce documented vulnerabilities that attackers can exploit to compromise the application. Keeping packages updated is a core security baseline.
Run `bundle update` to upgrade affected gems, or `bundle audit check` to list advisories. Pin patched versions in your Gemfile.
id: dependencies.dev-deps-in-prod🔗
Development-only dependencies are installed in the production dependency tree.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Move this dependency from dependencies to devDependencies in package.json.
id: dependencies.unpinned-versions🔗
Package.json contains version ranges (^, ~, *, latest) instead of exact pinned versions.
Unpinned dependency versions make builds non-deterministic and expose the application to unexpected breaking updates or supply-chain attacks.
Pin this dependency to an exact version. Replace ^, ~, *, or latest with a specific version number.
id: dependencies.html-cdn-unpinned-versions🔗
CDN dependencies without exact versions can change unexpectedly and should be pinned
Unpinned dependency versions make builds non-deterministic and expose the application to unexpected breaking updates or supply-chain attacks.
Pin the CDN asset to an exact version and use Subresource Integrity or self-host the dependency.
id: dependencies.cargo-unpinned-versions🔗
Cargo.toml dependency with wildcard, bare semver, or unpinned git reference. Pin to an exact version.
Unpinned dependency versions make builds non-deterministic and expose the application to unexpected breaking updates or supply-chain attacks.
Pin to an exact semver version (e.g. "1.2.3"). For git dependencies, include a rev, tag, or branch.
id: dependencies.deprecated-functions🔗
Use of a Node.js or library function that has been deprecated.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Replace deprecated functions with their recommended alternatives. Check the library migration guide.
id: configuration.secrets-in-source🔗
Secrets in source rather than environment variables
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Use environment variables instead. Store the secret value in process.env and reference it by key name.
id: configuration.default-credentials🔗
Default or hardcoded credentials are used instead of unique, environment-specific credentials.
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Change default credentials immediately. Use strong, unique passwords and store them in environment variables.
id: configuration.missing-ssl-verification🔗
rejectUnauthorized set to false, disabling TLS certificate validation.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Never set rejectUnauthorized to false in production. Use proper TLS certificates.
id: configuration.no-env-separation🔗
Configuration does not differentiate between development, staging, and production environments.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Create separate config files per environment or use environment variables to differentiate dev/staging/prod settings.
id: configuration.insecure-cookie-flags🔗
Cookie set without explicit security flags (HttpOnly, Secure, SameSite).
Weak session identifiers or insecure cookies can be intercepted or predicted by attackers, leading to session hijacking and unauthorized account access.
Set HttpOnly, Secure, and SameSite=Strict on session cookies.
id: data-exposure.verbose-errors🔗
Error responses include stack traces or internal details, leaking implementation information to clients.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Catch errors in your middleware and return generic error messages to clients. Log the full error server-side only.
id: data-exposure.pii-in-responses🔗
API responses include personally identifiable information without proper filtering.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Filter API responses to exclude PII fields. Use select or projection to return only necessary fields.
id: data-exposure.no-response-filtering🔗
API responses return full database rows without filtering sensitive or unnecessary fields.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Select only the fields you need from database queries. Never return full rows to clients without filtering.
id: data-exposure.unprotected-sensitive-sql-columns🔗
Storing highly sensitive fields (like SSNs, cards, or plain API keys) without encryption or hashing poses high data exposure risks.
Unsafe database interactions and weak permissions allow SQL injection or unauthorized data exposure, compromising data confidentiality and integrity.
Encrypt sensitive data columns at rest, or use hashed/digest representations for fields like passwords or API tokens.
id: data-exposure.html-form-pii-exposure🔗
Forms should not keep PII in hidden inputs or expose sensitive autofill settings on fields
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Avoid storing PII in hidden inputs and set autocomplete="off" on sensitive fields. Keep sensitive data server-side when possible.
id: data-exposure.plaintext-secret-in-email🔗
Detects license keys, tokens, or API keys rendered in plain-text email bodies without warning that email is not encrypted in transit
Sending license keys or credentials in plaintext email bodies exposes them to interception or unauthorized access, as standard email is not encrypted in transit (CWE-319).
Add a warning to the plain-text email body that email is not encrypted in transit. Consider omitting the secret from the plain-text part entirely, or linking to a secure dashboard instead.
id: data-exposure.composite-pii🔗
Multiple PII attributes collected together enabling re-identification
Combining seemingly harmless fields can uniquely identify individuals. This violates privacy regulations (GDPR, CCPA) and exposes users to identity theft (CWE-359).
Split or pseudonymise composite PII fields. Avoid storing multiple identifying attributes in the same record or API response.
id: data-exposure.derived-identifiers🔗
Derived or synthetic identifiers that enable record linkage across sessions or datasets
Derived identifiers can re-identify pseudonymised users and track them without their consent. This undermines privacy guarantees and may violate regulations (CWE-359).
Avoid creating derived identifiers from user data for tracking or correlation. Use anonymous session tokens that cannot be reversed to identify the user.
id: data-exposure.unredacted-logs🔗
PII or sensitive data written to logs without redaction
Logs are often stored in plaintext, aggregated across services, and accessible to many engineers. Unredacted PII in logs is a frequent source of data breaches and compliance violations (CWE-532).
Redact or mask sensitive fields before logging. Use a structured logging library with automatic PII scrubbing or log only non-sensitive summary data.
id: data-exposure.localstorage-sensitive-data🔗
Storing sensitive data (password, token, secret) in localStorage is insecure.
Failing to address this issue can lead to security vulnerabilities, operational failures, or data exposure, compromising the safety and reliability of your application.
Do not store sensitive data in localStorage. Use httpOnly cookies or secure server-side storage.
id: data-exposure.debug-artifacts🔗
Debugger statement or debug import left in production code, potentially exposing runtime state.
Improper logging and monitoring configurations can expose sensitive debugging details to attackers or fail to provide alert visibility during active service outages.
Remove debugger statements and debug imports before deploying to production.
id: data-exposure.hardcoded-ip🔗
A literal IP address in source code, which may leak internal infrastructure details.
Exposing secrets or environment configuration details in source code makes them accessible to unauthorized users and increases the threat surface of the infrastructure.
Move IP addresses to configuration or environment variables. Use DNS names where possible.