The Attacker Doesn’t Need to Know Your Programming Language Anymore

LLMs did not make attackers smarter. They made them cheaper. What your front end has always told the world, and why reading it just got easy.

Someone who has never written a line of PHP, Python or Ruby opens your website, saves the page, and pastes it into an LLM. Ten minutes later they know which framework you run, roughly which version, the names of some of your libraries, and that one of those libraries has a public, unpatched security hole. They did not learn the programming language. They asked a tool that already knows it.

Attacks got cheaper

For years, reading a web app to find its weak spots was expert work. It took time, and time filtered out most attackers. That filter was doing security work for you, quietly and for free, and you never wrote it down anywhere. LLMs remove the filter. Work that used to cost a skilled attacker an afternoon now costs anyone a few cents and one good question. The danger is not a genius. It is a normal attacker, running cheap, at scale.

The attacker used to need to know Ruby and be an expert in Devise or another critical gem to attack your Rails app. Now they need to know how to ask. The expertise moved into the tool.

Your front end was always public

Everything the LLM reads was already sitting in the browser of every visitor you ever had. The HTML, the JavaScript, the requests your page makes: public, all of it, all along. It was just boring to read, so mostly only experts bothered.

Security through obscurity was always a loan. This is the notice that the loan is due.

What your front end gives away

Point a curious tool at your client code and here is what tends to fall out:

• Source maps. If you ship them to production, you are handing over your original server-side code, file names and all.
• Secrets that should never be in a browser: API keys, tokens, and internal URLs left inside the JavaScript.
• Version fingerprints. Error pages, response headers, cookie names, and the shape of your CSRF token all hint at your framework and its version. Match that version against a public list of known bugs and the attacker knows your weak spot before he sends a single real attack.
• Extra data in responses. Your screen shows five fields; the response behind it carries twenty, including internal IDs the user was never meant to see.
• GraphQL introspection left switched on, which is a full map of your API for anyone who asks for it.

What it does not give them, and why that still matters

Be clear about the limits, because this is where the hype gets it wrong.

Reading your HTML does not find a SQL injection and does not let anyone run code on your server. Those bugs live on the server. What the client gives the attacker is a map: where to aim. He still has to send real requests and watch how your server answers. The LLM helps him write those requests and read the replies, but the hole has to actually exist in your backend.

The client-side JavaScript runs in the attacker's own browser, not on your machine, so it does not hand him control of your server. The real client-side risks are different, and still serious: leaked secrets, a script flaw that harms your other users, and actions that are hidden in the interface but left unguarded on the server. Hiding a button is not the same as protecting what the button does.

The part that clicks for itself

Newer tools do not just read the page. They drive it. An LLM connected to a browser can open your app, click every button, flip every switch, and try every path, without getting tired and without the rhythm of a human. It is patient in the way only software is.

That is your bot problem again, wearing a new coat. The same rhythm that gives away a fake signup gives away an automated prober: every link touched, every field tried, no pauses, no daylight.

The good news: it works for you too

The tool that reads your app for an attacker will read it for you first, and for less than the price of a coffee. Point it at your own site before he does. Then fix what it finds:

• Put the real security check on the server, on every endpoint. The interface can hide a button; only the server can refuse the action behind it.
• Keep secrets out of the browser, and scan your built JavaScript for keys and tokens as part of your pipeline.
• Turn off source maps in production, or lock them behind a login. Remove version banners and detailed error pages.
• Patch fast, and run a tool that checks your libraries against known bugs (bundler-audit, Dependabot, or similar), so you find the vulnerable gem before the attacker's version lookup does.
• Turn off GraphQL introspection in production.
• Watch for traffic that clicks everything with no human rhythm, and slow it down.

The attacker did not get smarter. Reading your app just got cheap. Everything ou shipped to the browser, you shipped to him too. The fix is not to hide it better. It is to make sure nothing you hid was holding up the wall.

Takeaways

• LLMs lower the cost of attacking you, not the difficulty. The threat is a cheap attacker at scale, not a genius.
• Your front end was always public. An LLM just makes reading it fast and free.
• The client leaks maps and hints: source maps, secrets, version fingerprints, extra fields, open API introspection. Version plus a known bug list is the dangerous new shortcut.
• SQL injection and server code execution still live on the server. The client tells the attacker where to aim, not that the hole exists.
• Use the same tool on yourself first. Then move every real check to the server, keep secrets out of the browser, and patch before the version lookup does.

I am a backend and systems engineer. I work on authentication, PKI, and cryptography in Ruby and C, and, occasionally, the fraud and abuse that come with running them. More at msuliq.github.io.