Do you ever lie awake thinking about all the weird ways a single web app can leak risk into the world? Or am I the only one who does that?

This framework started as a sketch in my notebook during a late-night debugging sprint. One of those “how the hell is this subdomain still live?” moments. It spiraled into a deep dive on how web applications — the ones we think we’ve “secured” — are actually bleeding exposure in ways we don’t always catch.  

The average organisation knows they run hundreds of applications. But the real number is likely higher than they think due to shadow IT, making it difficult for security teams to secure the “unknown” and keep track of their attack surface.

So I built a map, which then turned into *a framework*. A way to trace all the quiet, quirky, and critical ways your web app could be talking to the outside world.  

Not for compliance. Not for a report. For the people who actually have to fix it.

Why I Built This

Modern web apps are like shipping containers held together with duct tape and API keys. They move fast, they depend on everything, and they leave behind a trail of forgotten logins and dev environments.

If you don’t actively map your attack surface, it keeps expanding and mutating. So here’s the mental model I now use anytime I’m thinking about exposure. Seven vectors behind one mindset: continuous discovery.

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!

‍