DevMeth
C37

Access & auth

Math.random() Token Check — Are Your Tokens Actually Unguessable?

DevMeth checks the 48 known AI-code failure patternsnot a penetration test or a security guarantee.

What the issue is

Session tokens, reset links, and API keys made from Math.random() or timestamps are predictable — attackers can guess them and take over accounts.

Why AI tools generate it

AI generators default to Math.random().toString(36) for 'random strings' because tutorials use it — it looks random but is predictable by design.

How DevMeth detects it

A code scan flags Math.random()/Date.now() feeding token, secret, OTP, session, or API-key variables and token-generator functions returning them.

C37
What a finding looks like
High

Security tokens are generated with Math.random()

WHAT WE FOUND

C37masked sample

Sample — illustrative and masked exactly as a real report shows it. Run a free scan to see your own results.

The fix, in three steps

Swap Math.random() for crypto.randomUUID() or crypto.randomBytes(32).toString('hex') at each flagged line — one-line changes, same storage flow.

Run a free scan and each finding carries a paste-ready fix prompt you can act on.

Try a free scan

FAQ

Isn't Math.random() random enough?

It's a fast pseudo-random generator — fine for UI jitter and games, predictable for secrets. Its internal state can be reconstructed from a few outputs.

Why is Date.now() flagged too?

A timestamp has no entropy at all. An attacker knows roughly when a token was issued and can enumerate millisecond values.

What's the fix?

crypto.randomUUID() or crypto.randomBytes(32).toString('hex') on the server, crypto.getRandomValues in the browser. Same variable, same storage — a real random source.

DevMeth checks the 48 known AI-code failure patternsnot a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.