Attack Surfaces

Your attack surface is every point where someone could try to get into your system: every open port, every running service, every piece of old code and every account that could be logged into. HTTPS protects one of those points. Security is about knowing all the others, and having fewer of them.

What counts as an attack surface

An attack surface is the sum of all the ways an attacker could interact with your system. Each individual way in is sometimes called an 'attack vector' or 'entry point'. For a typical web app, they fall into three rough groups:

• Network: every port that accepts connections from the internet, and whatever service is listening on it.
• Software: every application, library and framework you run, at the version you run it. That includes the ones you forgot about.
• People and accounts: every login, API key and password that grants access, and how well each one is protected.

The key word is every. An attacker doesn't need to beat your strongest defence. They need to find the one entry point you didn't think about. That is why the size of the surface matters as much as how well any single part is protected.

Why HTTPS isn't the whole story

HTTPS is worth having. It encrypts the traffic between a browser and your server, so nobody on the same café Wi-Fi can read or change it. The padlock in the address bar means exactly that, and nothing more.

It says nothing about:

• what else is listening on the same server;
• whether the software behind the site has known vulnerabilities;
• whether the admin password is also used on a dozen other sites.

A site can have a perfect padlock and an SSH login open to the whole internet. The padlock guards the front door while the side windows stay open. Feeling safe because of one visible control is one of the most common ways people underestimate their exposure.

Open ports: doors you forgot to lock

A port is a numbered endpoint on a machine that a service listens on. Web traffic usually arrives on 443 (HTTPS) or 80 (HTTP). Two others the video mentions are worth knowing:

• Port 22 is SSH, used to log in to a server remotely.
• Port 3389 is RDP, Microsoft's Remote Desktop.

Both are there for administrators, not the public. Left open to the whole internet, they are found quickly: automated scanners sweep the internet around the clock looking for exactly these ports, then try common passwords or known exploits against whatever answers.

The same goes for a database port, a monitoring dashboard or a debug server someone started 'just for a minute'. If it accepts connections from anywhere, it is part of your attack surface, whether or not you meant it to be.

Old software that nobody updated

Software vulnerabilities are found all the time. When one is, it is usually given a public identifier (a CVE) and the vendor ships a fix. From that moment, the vulnerability is public knowledge, and so is the list of versions that have it.

That is what makes forgotten software dangerous. An old staging site, a test API from last year's hackathon or a plugin nobody remembers installing keeps running the version it had on the day it was set up. Nobody patches it because nobody is looking at it. Attackers, meanwhile, scan for exactly those versions.

The same applies to dependencies inside an app you do maintain. A web framework, an image library or a logging package with a known flaw is part of your attack surface even if your own code is flawless. Keeping container images small helps here too: fewer packages means fewer things to patch, which is the idea behind distroless images.

Every new service adds another way in

Each feature you add tends to add entry points: a new API endpoint, an admin panel, a file upload, a third-party integration, a storage bucket, a second server. None of them is a mistake on its own. The trouble is that they add up, and each one needs its own care: access rules, updates and monitoring.

The harder problem is keeping track. As a system grows, it becomes difficult for any one person to name everything that is running. A service you don't know about can't be patched, locked down or switched off. That is why security teams start with an inventory: a list of every domain, server, service and account the organisation owns. You can't shrink a surface you can't see.

Reused passwords stretch it beyond your own systems

Your attack surface isn't limited to servers you run. If you reuse a password, every site that has that password is part of it.

Small sites get breached, and their user tables leak. Those lists of email addresses and passwords are copied, sold and shared, and they don't go away: a password leaked years ago can still be tried today. Attackers feed the lists into automated tools that try each email and password pair on other services. This is called credential stuffing, and it works because so many people use the same password everywhere.

So a breach of a forum you joined years ago can lead straight to your email, your cloud account or the admin login of your app. The fixes are well established:

• a unique password for every account, which in practice means a password manager;
• multi-factor authentication on anything important, so a leaked password alone isn't enough;
• checking whether your email address appears in known breaches, and changing any password that did.

A worked example: auditing a side project

Say you run a small app on a single cloud server. It has a valid HTTPS certificate and you consider it done. A short audit might find this:

1. SSH on port 22 accepts logins from anywhere, with password login enabled.
2. PostgreSQL is listening on port 5432 on every network interface, not just locally.
3. An old staging subdomain still runs a version of the app from a year ago.
4. The database admin account uses the same password as an old forum account.

Start by listing what is actually listening on the server:

# TCP ports in the listening state,
# with the process behind each one
sudo ss -tlnp

Then look from the outside, the way an attacker would. Only scan machines you own or have permission to test:

# Scan the most common 1,000 TCP ports
nmap -Pn your-server.example.com

Next, close everything that doesn't need to be public. With ufw on Ubuntu, a default-deny firewall that only allows HTTPS, plus SSH from your own address, looks like this:

sudo ufw default deny incoming
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 \
  to any port 22 proto tcp
sudo ufw enable

Add the SSH rule before enabling the firewall, or you can lock yourself out. Then work through the rest of the list: bind PostgreSQL to localhost so only the app can reach it, switch SSH to key-based login, delete the staging site (or patch it and put it behind a login), and give the database account a new, unique password.

None of these steps is dramatic. Together they leave the app with two ways in, each one deliberate: HTTPS for the public and key-only SSH for you.

When to review it

Treat the attack surface as something that changes, not a box you tick once. Good moments to look again:

• when you add a service, a port, an integration or a new environment;
• when you retire something, to make sure it is actually switched off;
• when a major vulnerability is announced in software you use;
• on a regular schedule, even when nothing seems to have changed.

Common mistakes

• Treating HTTPS as the whole of security. It protects data in transit and nothing else.
• Leaving admin services open to the internet. SSH, RDP and database ports should be restricted to the people who need them.
• Forgetting old environments. Staging sites, demos and test servers need patching or deleting, not ignoring.
• Patching the app but not its dependencies. A vulnerable library is just as exploitable as a vulnerable line of your own code.
• Reusing passwords. One breach anywhere becomes a way into everything that shares the password.

Key takeaways

• Your attack surface is every way into your system: ports, services, software versions and accounts.
• HTTPS protects traffic in transit; it doesn't close open ports or patch old code.
• Close ports you don't need, and update or remove software nobody maintains.
• Keep an inventory: you can't protect what you don't know is running.
• You can't control the wider internet, but you can control how much of your system it can reach.