Trust Boundaries and Attack Surface
The attack surface is the sum of every point where an attacker can try to get in or get data out: every open port, every input field, every API, every dependency, every person with a login. A trust boundary is any line where data or control passes between components that trust each other differently. Much of security is the disciplined shrinking of the first and hardening of the second.
You cannot defend what you have not enumerated, so this topic is about seeing Meridian the way an attacker does — as a list of reachable things — and then making that list shorter and each item on it harder to abuse.
Enumerating the Surface
For Meridian that means listing far more than open ports: the web app and its every input, the API and its every endpoint, SSH, the third-party libraries the app ships, and the employees and credentials that can reach any of it. The widest surfaces are rarely the open ports — they are the input fields, the dependencies, and the people, which is exactly why teams undercount them.
Trust Boundaries, Concretely
Three boundaries matter most for Meridian: the browser-to-server line, where untrusted user input arrives; the app-to-database line, where a query built from that input can turn into injection; and the corporate-network-to-production line, where a phished laptop must not be able to reach the customer database. Each is a place where "trusted" on one side meets "untrusted" on the other, and each needs validation and authentication at the crossing.
Reducing the Surface
Every element removed is one that cannot be attacked. Close unused ports, delete dead endpoints and feature flags, drop dependencies you do not need, and revoke standing access nobody uses. Dormant, unmaintained surface is where attackers look first, precisely because nobody is watching it. Default to closed and require a reason to open anything.
The Surface Teams Forget
Employees who can be phished and dependencies that can be poisoned are as much attack surface as an open port — and the ones most often left off the list. So is exposure itself: a service on localhost and the same service on the public internet are identical code but wildly different risk. Where something lives changes its risk as much as what it is, which is why an accidentally internet-exposed debug port is such a common and costly mistake.
- Counting only network ports as attack surface and ignoring inputs, dependencies, and people — the widest surfaces are rarely the ports.
- Leaving old endpoints and feature flags live "just in case," creating dormant surface nobody monitors and attackers probe first.
- Accidentally exposing an internal service — a debug port, a management console — to the internet and rating it low-risk because it is "internal."
- Adding a dependency without counting it as surface, when every library pulled in is code you now ship and must trust.
- Treating internal and internet-facing exposure as the same risk tier, so the same weak control guards both.
- Maintain an inventory of exposed services, inputs, and dependencies — attack-surface management starts with an accurate list.
- Default to closed: expose the minimum and require a documented reason to open anything.
- Prune ruthlessly — delete dead endpoints, retire unused features, and drop dependencies you do not need.
- Place controls at every trust boundary, not only at the perimeter, since internal crossings carry real threats too.
- Treat internal and external exposure as different risk tiers, and watch the internet-facing surface most closely.
Knowledge Check
Why is an internal service accidentally exposed to the internet more dangerous than the same service on localhost?
- Exposure makes the identical code reachable by every attacker online
- Internet-facing code is always written less carefully than internal code
- Localhost services cannot be attacked under any circumstances
- The service automatically loses its authentication when exposed
Which item is most often left off an attack-surface inventory?
- Phishable employees and third-party dependencies
- The list of open TCP ports on public-facing hosts
- The main customer-facing production web application itself
- The company's primary domain name
What does "default to closed" mean for attack surface?
- Expose the minimum; require a reason to open anything
- Shut the entire system down whenever it is not actively in use
- Open everything first and remove access only after an incident
- Rely on a deny-list of known-bad inputs to block attacks
You got correct