In one of those late-night debugging sessions, I was staring at a subdomain that shouldn't have been live. It was attached to a decommissioned app. The DNS record was still there, pointing at infrastructure that was never cleaned up, running a version of something that hadn't been patched in eighteen months. And it was connected to production.
Nobody had mapped it, and the team that built it had moved on. This is the default state of most environments: not compromised, not protected, just quietly accumulating surface.
I started thinking about what became this framework that night, as a resource for the people who have to actually understand what's happening and then go fix it.
The average organization thinks it knows how many web applications it runs. The real number is almost always higher, with Shadow IT adding to it constantly. What you think you're securing and what is actually exposed are rarely the same list.
Modern web applications compound this, because they depend on everything. Scripts loaded from third-party CDNs, authentication layers from one vendor, analytics from another, APIs calling into four more. Each dependency is a connection your scanner doesn't always follow. Each one is a surface you're responsible for whether or not you know it exists.
So the mental model I use when I'm thinking about exposure comes down to seven vectors, because these are the seven places I keep finding things that security teams didn't know were there. Every one of them maps to something real I have seen in a customer environment.
The mindset behind all of them is the same: continuous discovery. Not a scan you run before the audit, but a living view that updates as the environment changes, because the environment changes constantly and attackers don't wait for your next scheduled assessment.
The 7 Attack Surface Vectors I Always Check
These seven are my go-tos. If you're shipping or securing a web app, start here:
1. Security Mechanisms
This is step zero. How is the app securing its traffic?
I’m talking TLS configs, HTTPS enforcement, HTTP headers, cert expiration, HSTS. The stuff that’s supposed to be invisible… until it’s not.
2. How the Page Was Built
You want to know how it was made, not just what it does.
The coding language, the framework, the dev toolchain — all of that leaves fingerprints. And those fingerprints lead to patterns. And those patterns lead to predictable flaws.
You can tell a lot about a dev team’s hygiene from the tech stack they commit to prod.
3. Degree of Distribution
The more public-facing pages, micro-frontends, marketing subdomains, and forgotten portals… the wider your attack surface area. Distribution = exposure.
I like to think of this as “how loud is this app on the internet?” If it’s chatty, it’s risky.
4. Authentication & Access Control
Who’s allowed in? Who shouldn’t be?
Weak auth schemes, open endpoints, forgotten admin panels — I’ve seen them all. Access controls should be strict, intentional, and reviewed. Not "set once and ignored forever."
Also, I still see lots of “admin/admin” on staging...
5. Input Vectors
Input is a beautiful thing, until someone injects a payload into your form field.
Every field, query param, and upload button is a potential toy for attackers. Think XSS, SQLi, header injections. If it accepts input, it deserves scrutiny.
Rule of thumb: the more ways users can talk to your app, the more ways attackers will.
6. Active Content
Active content makes the app feel alive. It also makes it a bigger target.
Scripts, plugins, dynamic rendering, client-side execution — anything that runs actively can misbehave creatively. Especially if you’re still using that jQuery plugin from 2014.
Control the script party, or someone else will.
7. Cookies & Sessions
Poorly scoped cookies, missing flags, insecure storage... they all add up to session hijacking and privilege escalation. I always dig into cookie behavior when I’m reverse-engineering auth flows.
Set your flags. Lock down your sessions. And no, JWTs aren’t magic.
How I Use This In Practice
I treat this like a checklist and a compass. Whenever I’m reviewing a product, breaking down a new integration, or doing a recon pass, I walk through all seven.
It’s not just “what do we have?” — it’s “what do we not know we still have?”. Because exposure isn’t always about what’s online; it’s about what’s still connected. This and other External Attack Surface Management (EASM) best practices can help get your house in order and reduce shadow IT risks.
And here’s the kicker: once you’ve mapped the exposed bits, you’ve got to correlate them against business criticality and the frequency of updates, in order to determine the overall risk posture.
That’s how you figure out your security posture, and that of your third-party vendors and suppliers. Rather than thinking "what’s broken", think "what matters most if it breaks."
And that’s when the real magic happens:
When you know your total addressable attack surface , you can put your controls in exactly the right places. You can make a bigger impact with security that supports the business, not slows it down.
This is part of how we build at ThingsRecon. The product itself is shaped by this thinking — always looking around corners, asking “what else is here?”, and pulling threads until something falls out of the wall. But that’s another story.
TL;DR
If you’re securing a web app and you’re only thinking about what’s in production, you're missing the real surface area. The random stuff is where the fun (and the risk) lives.
So next time you're doing a review, pull out these seven. Treat them like a scavenger hunt. I promise they’ll surprise you.
And if you're into mapping digital stuff like this, let's talk!
