A hardcoded string constant is being used as a Content Security Policy (CSP) nonce. CSP nonces must be cryptographically random and unique per request. Hardcoded or predictable nonces allow attackers to bypass CSP script execution protections.
Rule Explorer
Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
- Public rules
- 4797
- Downloads
- 12.1M
- Verified
- 4797
- Authors
- 2
getentropy() returns 0 on success and -1 on error. Directly assigning or casting its return value to a boolean inverts the success check, treating success (0) as false and failure (-1) as true. Check for success explicitly with `getentropy(...) == 0`.
Importing SecureRandom from 'jsbn' is cryptographically insecure in non-browser environments like Node.js because jsbn falls back to an ARC4 PRNG seeded with Math.random() and timestamps. Use Node's crypto module or globalThis.crypto instead.
MongoDB `ObjectId`s are predictably generated based on a timestamp, process ID, and counter. When used as primary identifiers (`id` or `_id`) in systems that assume these IDs are opaque and unguessable (like invitation tokens, session IDs, or password reset links), attackers can predict them and bypass authorization. Replace `new ObjectId()` with explicitly
Deriving a JWT secret key using an MD5 hash restricts the key's entropy to at most 128 bits and can make tokens vulnerable to offline forgery attacks, especially if the hashed input (like a password) is predictable. Use a cryptographically secure random value generation (e.g., SecureRandom or UUIDs) for symmetric signature secrets.
Directly extracting the exact 'd' closest peers from the routing table for Kademlia DHT disjoint paths leaves the lookup vulnerable to Sybil/Eclipse attacks. If an attacker controls the 'd' closest node IDs, they will intercept and control all query paths. Fix this by retrieving a wider pool of closest peers (e.g., `kBucketSize`) and drawing from it probabil
Generating a session token or credentials directly from a process ID (PID) makes the token highly predictable. Attackers can guess valid tokens to hijack sessions or trigger unauthorized actions. Use a cryptographically secure random number generator (CSPRNG) to generate session identifiers.
Cryptographic operations from underlying libraries are returned directly without checking for failure (e.g., null returns from JNI wrappers or uncaught exceptions). This can cause fallbacks to all-zero keys, leading to deterministic and predictable key material. Properly handle failures by checking for null or catching exceptions and throwing a dedicated Cry
A potentially hardcoded or static seed is used for MurmurHash3 initialization. This makes the hash function predictable and vulnerable to hash collision Denial of Service (DoS) attacks. An attacker can precompute keys that hash to the same bucket, degrading performance to O(n²). Randomize the hash seed using a cryptographically secure pseudo-random number ge
The application manually constructs a temporary file name using a predictable pseudo-random generator and opens it. An attacker can predict the sequence of random values, pre-create the expected file, and cause a denial-of-service or a race condition by forcing the O_EXCL file creation to fail. Use os.CreateTemp, os.MkdirTemp, or cryptographic randomness (cr
Constructing temporary file, link, or directory paths using custom or weak random string generation functions (e.g., math/rand or custom utils) and passing them to file creation APIs like `os.OpenFile`, `os.Symlink`, or `os.Link` is prone to predictability and collision (EEXIST) attacks. This can be exploited to cause a local denial-of-service or privilege e
Generating bytes with Perl's built-in rand() (e.g. `chr rand 256`) is insecure for any cryptographic purpose. Perl's rand() is a non-CSPRNG with a small, predictable internal state; bytes derived from it can be reproduced or brute-forced by an attacker. Use an OS CSPRNG such as Crypt::SysRandom::random_bytes(), Crypt::URandom, or Crypt::PRNG instead.
Authentication/API token is generated using itsdangerous.URLSafeTimedSerializer keyed by a non-secret value (e.g. tenant_id) and/or signing a predictable payload such as a UUID, with the output being sliced. This treats the serializer as a randomness source instead of a verifiable signed token. URLSafeTimedSerializer produces deterministic base64(payload).ti
A user/session/API token is generated using `:base62.encode/1` without sourcing entropy from `:crypto.strong_rand_bytes/1`. This pattern produces structurally-predictable tokens (especially when combined with HMAC over user-identifiable inputs) that are brute-forceable or enumerable (CVE-2025-64097, CWE-330). Replace the token body with `:crypto.strong_rand_
Session/token identifier is derived by hashing the output of Perl's built-in rand(), which is a non-cryptographic PRNG seeded with only ~32 bits and is therefore predictable. Combining it with $$ (PID), time, or stringified references (memory addresses) does not add meaningful entropy, and wrapping the result in a digest (sha1_hex/md5_hex/sha256_hex/...) doe
Generating session seeds or cryptographic tokens using weak sources of entropy like `time` and `rand` leads to highly predictable values. An attacker can brute-force or correlate these inputs to guess the final output, leading to session hijacking. Use a true CSPRNG (e.g., Crypt::SysRandom or Math::Random::Secure) instead.
Perl's built-in rand() is being fed into a cryptographic hash (SHA-1/SHA-256/SHA-512/MD5) to derive bytes. rand() is seeded with at most 32 bits and is not a CSPRNG, so hashing it (optionally with $$, Time::HiRes::time, or other low-entropy values) does not produce cryptographically strong output. This pattern produces predictable session IDs, CSRF tokens, a
Mojolicious applications and framework code should not use the predictable application moniker or insecure PRNGs like `rand` to generate session secrets or CSRF tokens. This allows an attacker to compute valid HMAC signatures and forge session cookies. Replace predictable secrets with strong cryptographic random strings (e.g. `Mojo::Util::urandom_urlsafe`).
Constructing temporary files manually using random strings is vulnerable to predictable temp file collision attacks (Insecure Temporary File). An attacker who can predict the target path and pseudorandom component can pre-create the file and trigger Denial of Service or unauthorized access. Use standard secure temp file creation utilities like `os.CreateTemp
Predictable TCP Initial Sequence Number (ISN) generation detected. Generate ISNs using a cryptographically secure pseudo-random number generator (CSPRNG) or a secure hash that incorporates connection parameters and a secret key, as recommended by RFC 9293. Incrementing a variable to compute the ISN makes it predictable, rendering the stack susceptible to TCP