Most security failures I see today aren’t caused by carelessness.

They’re caused by engineers who were never forced to understand how the web actually works.

At some point, security stopped being something most engineers were forced to internalize.

Not because people became careless. But because the tools, abstractions, and workflows changed.

Today we have security engineers, AppSec teams, audits, scanners. All good things. Necessary things.

But they’re not replacements for a basic understanding—and that’s what’s missing.

I routinely see junior engineers who don’t understand basic client–server architecture. Who don’t know what data is actually trusted. Who’ve never thought seriously about attack vectors like SQL injection, session hijacking, or XSS—not in theory, and definitely not in practice.

I don’t know if this is a failure of schools, bootcamps, or the content we emphasize—but it feels different from when I was learning.

I grew up in an era where curiosity about how things actually worked was unavoidable.

Web browsers weren’t always this good.

In the IE4/IE5.5/IE6 days, debugging meant “View Source” and a cryptic JavaScript error popup. No DOM inspector. No network visibility. No easy way to understand what was actually happening between the browser and the server.

So you had to dig deeper—packet captures, raw HTTP, whatever tools you could get your hands on.

Back then, it wasn’t unusual to see session IDs, user IDs, or even privilege-related data sitting plainly in URLs and form submissions—easy to modify if you cared to look. And when that happened on your site, you had to understand how it was done so you could fix it.

It wasn’t easy to understand how the web worked—but it was necessary. At least until it wasn’t.

Firebug.

Firebug was revolutionary. It made the web observable. For the first time, you could really inspect the DOM and actually see JavaScript execute. You didn’t just fix bugs—you learned how the browser worked.

Chrome later took that idea and turned it into a first-class, default experience. DevTools became faster, deeper, and something every engineer actually used—especially with the Network tab. But Firebug was the spark.

Another thing that feels lost from that era is the excitement around reverse-engineering.

Back then, if something cool existed on the web, people wanted to pull it apart. View Source wasn’t just a tool—it was a learning mechanism. Curiosity was baked in.

Today, that instinct feels rarer. It isn’t gone, but people often rely on others to do it for them—and then just read the Hacker News article.

And when curiosity fades, so does intuition.

What’s different now isn’t that these systems are simple—they’re complex again.

In a strange way, we’ve drifted toward something that looks like security by obscurity. Not because anyone believes in it—but because you no longer really need to know how it all works.

Most of the time, it just does. And when it doesn’t, there are clear places to look for why.

Observability has made the inner workings of systems transparent—but transparent in the invisible sense of the word, not the clarity sense.

A quick story.

About ten years ago, a friend of mine was building his first Rails app. He sent me a link to check it out. Within minutes, I’d elevated myself to admin.

Not because he was careless—because he misunderstood one core concept of web development:

You can never trust the client.

That sentence echoes in my head constantly—almost to a fault.

And this might surprise some people, but for virtually every popular web application, there exist heavily modified clients designed to interact with it in unorthodox ways.

Ticketing platforms. Online games. Marketplaces. All social media websites. Everything.

And this isn’t new. We saw it with MySpace and eBay years ago.

If the client can send it, an attacker can manipulate it.

So the moral here is simple—and twofold:

  • Never trust the client. Ever.
  • Every engineer should understand basic security concepts and common attack vectors.

Security is not a separate discipline you bolt on later. It’s not a checkbox. It’s part of the job.