Which Ports Should a Web Server Expose? (Few)
80, 443 - and almost nothing else. What every extra open port advertises, how attackers inventory them, and a five-minute check of your own server.
Short answer
Public web servers should typically expose 80 and 443 only (80 to redirect). SSH should not be open to the whole internet if avoidable. Databases belong on private networks.
Five-minute check
From outside, review the host firewall or a responsible external port scan. Close surprises.
Internal "it is firewalled" claims fail when a cloud security group still allows 0.0.0.0/0.
Readers skimming which ports web server often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Admin access
Prefer VPN, tailnet, or break-glass paths over world-open SSH.
If SSH must be public temporarily, restrict by IP and log every session - then close it.
Common failure mode for which ports web server: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Databases and panels
Postgres, Redis, Elasticsearch, and admin UIs on the public internet are recurring breach openers.
Private networking is not overkill - it is the default for anything that holds data.
If this section on which ports web server becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- List security groups/firewall rules for production.
- Close anything that is not 80/443 (or justified + restricted).
- Move admin access behind VPN/tailnet if open to the world.
- Confirm databases have no public listeners.
Every open port is an advertisement.
Update log (1)
2026-07-09Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
