← mobang.fr

· Sécurité

Silent Flaws: When AI Code Works and Still Betrays You

A "silent flaw" is code that passes every test, runs in production without a hiccup... and exposes you anyway. The difference from a bug is simple: a bug breaks, and you see it right away. A logic vulnerability works perfectly — which is exactly what makes it dangerous. Nothing flashes red.

AI produces a lot of them, for a mechanical reason: it reproduces the simplified examples from its training data — the ones in tutorials — without the protections those tutorials leave out to stay readable. The code "works" perfectly, but it's missing the security layer nobody wrote.

The habit that protects you fits in one sentence: on sensitive areas — authentication, payment, file upload, password reset — you never trust the fact that "it works." You review, you scan, and you ask the AI to attack its own code. Here's how, with a very real example.

Bug vs vulnerability: why one shows and the other hides

A bug is broken behavior. The button doesn't respond, the page crashes, the total is wrong. Your tests catch it, your user complains, you fix it. The signal is immediate.

A logic vulnerability is the opposite. The code does exactly what you asked, in the normal case. It only fails against a use nobody planned for: a forged request, a measured response time, a repurposed field. As long as nobody looks, everything's fine. That silence is what traps vibecoders and rushed devs alike.

Keep the distinction in mind: a test checks that your code does what it should. Security checks that it does only that. Two different questions.

The example that says it all: password reset

The "Secure Vibe Coding" guide published by The Hacker News in June 2025 gives a telling example. You ask the AI for a password reset routine. It hands you clean code that compares the incoming token with the stored one:

// AI-generated: works perfectly
if (token === storedToken) {
  resetPassword(user);
}

Every test passes. The right token opens the door, a wrong one keeps it shut. And yet it's wide open.

The problem: === on strings stops at the first character that differs. Comparing "a..." takes a hair less time than comparing "ab...". Those microseconds are measurable. An attacker fires thousands of requests, times the responses, and rebuilds the token character by character. That's a timing attack.

The fix is a constant-time comparison — one that always takes the same duration regardless of the difference:

import { timingSafeEqual } from 'node:crypto';

const a = Buffer.from(token);
const b = Buffer.from(storedToken);
if (a.length === b.length && timingSafeEqual(a, b)) {
  resetPassword(user);
}

Same logic, same functional result. But the response time no longer leaks anything. The AI didn't write it this way on its own because nearly every tutorial uses ===: it's shorter to read.

Why AI writes "clean" code that's still full of holes

AI has no intent. It predicts the most likely continuation, and the most likely thing looks like the average tutorial. Tutorials deliberately cut the protections: input validation, secure comparison, permission handling. They bloat the example and don't help explain the concept. So the AI learned the simplified version as if it were the norm.

Hardcoded secrets follow the same slope. According to that same "Secure Vibe Coding" guide from The Hacker News, AI-assisted code repositories expose roughly 40% more secrets — API keys, hardcoded credentials — than traditional codebases. Same logic: in a tutorial snippet, apiKey = "sk-..." at the top of the file is more direct than a proper setup with environment variables.

None of this is inevitable. It's just a known blind spot — which means you can plan for it.

Your concrete defenses

You don't need to be a security expert. You need a few well-placed habits.

  • Targeted human review. Don't reread everything line by line. Aim your attention at the four areas that hurt: authentication, payment, upload, reset. That's 10% of the code and most of the risk.
  • Scanners in your CI. Wire a secret scanner and a vulnerability scanner into your pipeline. They run on every commit, tireless and never forgetful. A secret pushed by mistake gets caught before it reaches production.
  • Make the AI audit itself. Take the code it just wrote and switch hats: "You're an attacker. How would you break this code? List the vulnerabilities and attack vectors." The same model that produced the hole can often name it when you ask from that angle.
  • Secrets in environment variables. Never a hardcoded key in the code. A .env file ignored by Git, variables injected at runtime. Simple, and it closes the most common leak.

Where to start today

A short checklist you can run tonight on your project:

  1. List your sensitive areas. Write down, plainly, where auth, payment, upload, and reset live. You can't protect what you haven't named.
  2. Put the AI in attacker mode on each of those areas, one at a time, with the prompt above.
  3. Hunt for hardcoded secrets. A grep for key, secret, token, password across your code. Anything lying around moves to an environment variable.
  4. Add a scanner to your CI. Even a free, minimal one. What matters is that it runs on every push.
  5. Replace your token comparisons with a constant-time version everywhere a secret is compared.

None of these steps require expertise. They just require treating "it works" as the start of verification, not the end. That's the whole difference between code that passes the tests and code that holds up.