Why Math.random() Will Fail Your Next Security Audit

Tim O. — Fri, 10 Apr 2026 16:38:41 +0000

If you have ever written something like this in a production codebase:

const secret = Math.random().toString(36).slice(2);

You have shipped a credential that will fail a security audit.
Not might fail. Will fail.
Here is why that matters and what to do about it before your auditors find it first.
With the renewed focus on Executive Order 14028 and software supply chain security, auditors are no longer just looking at what libraries you use. They are looking at how you use them to generate internal secrets. Credential generation is now explicitly in scope for supply chain security reviews in ways it was not three years ago.
The problem with Math.random()
Math.random() is not a cryptographic function. It was never designed to be. It generates pseudorandom numbers that are fast and statistically distributed enough for things like shuffling a playlist or generating a random color. It is completely wrong for generating secrets, API keys, passwords, or any credential that needs to be unpredictable to an adversary.
The specific problem is predictability. Math.random() uses a deterministic algorithm seeded by the JavaScript engine. In some environments that seed is observable or reconstructible. In all environments the output fails the entropy requirements defined in NIST 800-63B, the federal standard for digital identity and credential strength.
When an auditor runs entropy analysis on your generated credentials and finds Math.random() in the generation path, the finding looks like this:

AUDIT FINDING — CRITICAL
Control: SC-28 / NIST 800-53

Finding: Credential generation function Math.random()
identified across microservices.

Impact: Generated secrets fail entropy requirements
for NIST 800-63B compliance. Cryptographic randomness
cannot be verified.

Status: OPEN - 90 day remediation required

That finding stops deals, delays launches, and costs engineering time to remediate retroactively. The fix at that point is expensive because you have to find every place Math.random() was used, replace it, rotate the affected credentials, and produce documentation proving the new generation method is compliant.
The right function is already in Node.js
You do not need a library. You do not need a third party service. Node.js ships with a cryptographically secure random number generator in the built-in crypto module:

`const { randomInt, randomBytes } = require('crypto');

// Generate a random integer between 0 and charset.length
const index = randomInt(0, charset.length);

// Generate random bytes for a hex token
const token = randomBytes(32).toString('hex');`

crypto.randomInt() uses the operating system's cryptographically secure pseudorandom number generator. On Linux that is /dev/urandom. The output passes NIST entropy requirements because the source of randomness is designed for exactly this purpose.
The fix is a one line change in most cases. The problem is that most teams never make it because nobody flags it until an auditor does.
A copy-paste utility for your codebase

If you want a drop-in replacement you can put in your utils/ folder today, here is a minimal version using only Node.js built-ins:

`const { randomInt } = require('crypto');

const CHARSETS = {
uppercase: 'ABCDEFGHJKLMNPQRSTUVWXYZ',
lowercase: 'abcdefghjkmnpqrstuvwxyz',
numbers: '23456789',
symbols: '!@#$%^&*'
};

function generateSecureCredential(length = 20, options = {}) {
const {
uppercase = true,
lowercase = true,
numbers = true,
symbols = false
} = options;

let charset = '';
if (uppercase) charset += CHARSETS.uppercase;
if (lowercase) charset += CHARSETS.lowercase;
if (numbers) charset += CHARSETS.numbers;
if (symbols) charset += CHARSETS.symbols;

if (!charset) throw new Error('At least one character set required');

return Array.from(
{ length },
() => charset[randomInt(0, charset.length)]
).join('');
}

// Usage
const secret = generateSecureCredential(20, {
uppercase: true,
lowercase: true,
numbers: true,
symbols: true
});`

This gives you cryptographic security but not compliance documentation. For NIST 800-63B audit trails, entropy calculation, and machine-readable compliance metadata, that is what you need to add on top of this foundation.
The documentation gap nobody talks about
Switching from Math.random() to crypto.randomInt() is the technical fix. But it does not solve the audit problem completely.
Auditors do not just want secure credentials. They want documented proof that credentials are secure. That means:

Entropy bits calculated per credential
Generation method documented at the time of creation
Compliance profile recorded alongside the credential

Most internal credential generation systems do not produce this documentation automatically. Engineers have to build it separately, maintain it, and make sure it stays accurate as the codebase evolves. Most teams never complete that work.
This is the gap that causes audit findings even when the underlying generation is technically correct. You fixed Math.random() but you have no proof you fixed it that satisfies an auditor asking for evidence.
What shift-left credential security looks like
The concept of shifting security left means solving security problems at the earliest possible point in the development workflow, not after auditors find them.
For credential generation that means every credential that ships should come with documented proof of how it was generated, what entropy it has, and which compliance standard it meets. That documentation should be automatic, not something an engineer produces manually six months later when someone asks for it.
If you want to automate that documentation piece entirely, this is how we structured the Six Sense API to handle it:

`const response = await fetch('https://api.sixsensesolutions.net/v1/generate', {
method: 'POST',
headers: {
'Authorization': 'Bearer your_api_key',
'Content-Type': 'application/json'
},
body: JSON.stringify({
length: 20,
quantity: 1,
compliance: 'NIST',
options: {
uppercase: true,
lowercase: true,
numbers: true,
symbols: true,
exclude_ambiguous: true
}
})
});

const { passwords, meta } = await response.json();

console.log(meta);
// {
// length: 20,
// entropy_bits: 120.4, // <-- This is your audit evidence. 120+ bits exceeds NIST minimum.
// generated_at: "2026-04-10T14:57:35Z",
// compliance_profile: "NIST",
// calls_remaining: 49999
// }`

Every response includes entropy_bits and compliance_profile in the metadata. That metadata is the audit documentation. Your auditor asks for proof that credentials meet NIST 800-63B. You show them the response metadata. The finding closes.
The free tier
If you want to test this in your own codebase, there is a free tier at sixsensesolutions.net with 500 calls per month and no credit card required. Signup generates a real API key instantly.
The NIST and SOC2 compliance profiles enforce minimum lengths, character requirements, and ambiguous character exclusion automatically. The strong profile respects whatever options you pass directly.
The takeaway
If your codebase contains Math.random() in any credential generation path, you have a finding waiting to happen. The technical fix is one line and the copy-paste utility above gives you that today for free. The documentation fix is what most teams skip and what auditors actually ask for.
Both need to be in place before your next audit, not after.

DEV Community: Tim O.

Why Math.random() Will Fail Your Next Security Audit