Port 80 – HTTP (Hypertext Transfer Protocol)

Port 80 is the default port for HTTP (Hypertext Transfer Protocol), the protocol browsers and servers use to exchange web pages, API calls, and form data. Everything on port 80 travels unencrypted, so anyone on the network path can read or rewrite it — which is why modern sites serve their content over HTTPS on port 443 and keep port 80 mostly to redirect visitors to the encrypted version. For anyone testing a host, it’s the front door: whatever web application answers on port 80 is usually the largest attack surface the box exposes.

Why It’s Open

Almost every web server still listens on 80. It catches clients that type a bare hostname, answers the Let’s Encrypt HTTP-01 challenge that issues TLS certificates, and 301-redirects everyone to HTTPS. Beyond public sites, you’ll find plain HTTP with no TLS at all on internal dashboards, routers, printers, IP cameras, and IoT firmware, on developer and staging servers, and behind reverse proxies and load balancers that terminate on 80 before handing traffic to an app server. The same web stack often answers on alternate HTTP ports like 8080, so a service you don’t see on 80 may just be one scan away.

Common Risks

• Cleartext by default. Session cookies, form posts, and HTTP Basic-Auth credentials all cross the wire in the clear. A machine on the path can sniff them with Wireshark or actively rewrite responses.
• The web app is the attack surface. SQL injection, XSS, SSRF, path traversal, and insecure deserialization all ride HTTP. Port 80 is just the door; the application behind it is where most findings live.
• Server-software CVEs off a banner. An exact Server: version can map straight to an exploit — Apache 2.4.49 path traversal, old IIS WebDAV overflow, an unpatched framework — no credentials required.
• Dangerous HTTP methods. PUT can drop a webshell into the web root; TRACE enables cross-site tracing; DELETE removes content.
• Request smuggling. When a front-end proxy and back-end server disagree on Content-Length versus Transfer-Encoding, an attacker can poison the request queue and hijack other users’ traffic.
• Constant automated scanning. Botnets hammer port 80 looking for exposed .git/.env, known webshells, and vulnerable CMS paths within minutes of a host coming online.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the server and read the headers

nmap -sV -p 80 --script=http-headers,http-title,http-methods,http-server-header <target>

Enumerate content with NSE

nmap -p 80 --script=http-enum <target>

Grab the banner and follow redirects

curl -sIL http://<target>/

Raw HEAD request with netcat

printf 'HEAD / HTTP/1.1\r\nHost: <target>\r\nConnection: close\r\n\r\n' | nc <target> 80

Fingerprint the web stack

whatweb http://<target>

Directory and file discovery

ffuf -u http://<target>/FUZZ -w /usr/share/wordlists/dirb/common.txt

Broad vulnerability scan

nikto -h http://<target>
nuclei -u http://<target>

Metasploit modules

msfconsole -q
use auxiliary/scanner/http/http_version
set RHOSTS <target>
run

use auxiliary/scanner/http/dir_scanner
set RHOSTS <target>
run

# Apache 2.4.49 / 2.4.50 path traversal → RCE (CVE-2021-41773 / CVE-2021-42013)
use exploit/multi/http/apache_normalize_path_rce
set RHOSTS <target>
run

Record every open instance, banner version, and exposed path you confirm so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

• CVE-2021-41773 — Path traversal in Apache HTTP Server 2.4.49, and remote code execution when mod_cgi is enabled and the default Require all denied is missing. The 2.4.50 fix was incomplete, reopened as CVE-2021-42013. Mass-exploited within days; ready-made as Metasploit’s exploit/multi/http/apache_normalize_path_rce and Exploit-DB 50383.
• CVE-2017-5638 — Apache Struts 2 Jakarta Multipart parser. A crafted Content-Type header is evaluated as an OGNL expression, giving unauthenticated RCE. This is the Equifax breach vector — Metasploit exploit/multi/http/struts2_content_type_ognl, Exploit-DB 41570.
• CVE-2021-44228 — Log4Shell. A JNDI lookup string like ${jndi:ldap://...} placed in any HTTP header or parameter that a vulnerable Log4j2 app logs triggers remote class loading and code execution. Trivial to test over port 80, catastrophic in reach.
• CVE-2017-7269 — Buffer overflow in the WebDAV ScStoragePathFromUrl function in IIS 6.0 (Windows Server 2003), triggered by a long If: header in a PROPFIND request. Exploited in the wild as “ExplodingCan” — Metasploit exploit/windows/iis/iis_webdav_scstoragepathfromurl, Exploit-DB 41738.

Mitigation

• Redirect everything to HTTPS. Answer port 80 with a 301 to the HTTPS site on port 443 and send HSTS (ideally with preload) so browsers never make the cleartext hop again.
• Patch the web server and framework. The fastest port-80 compromises come straight off an old Apache, IIS, or Struts banner — keep the stack current and strip the exact version from Server:.
• Lock down HTTP methods. Disable PUT, DELETE, and TRACE unless a specific app needs them.
• Add the security headers. CSP, X-Frame-Options/frame-ancestors, and X-Content-Type-Options close off whole classes of client-side attacks.
• Keep secrets out of the web root and put a WAF in front of the app to filter the constant scanning.
• Firewall raw access. Leave 80 open for redirects and the ACME challenge, but restrict admin panels and app endpoints to a management range.

Real-World Example

The 2017 Equifax breach started with an unpatched HTTP request. A fix for the Apache Struts 2 flaw (CVE-2017-5638) shipped in March 2017, but Equifax left a public-facing web app unpatched. From mid-May, attackers sent crafted Content-Type headers that Struts evaluated as code, and used that foothold to exfiltrate personal data on about 147 million people before anyone noticed in late July. One vulnerable web application on a web port, one missed patch — and one of the largest breaches on record.

FAQ

What is port 80 used for?

Port 80 is the default port for HTTP, the protocol that serves web pages, web apps, and API traffic. When you visit a site without typing https://, the browser tries port 80 first. The catch is that HTTP is unencrypted, so most servers now use port 80 only to redirect visitors to HTTPS on port 443.

What is the difference between port 80 and port 443?

Port 80 carries plain HTTP; port 443 carries HTTPS, the same protocol wrapped in TLS encryption. On 80 the traffic is readable and modifiable on the wire; on 443 it’s encrypted and authenticated with a certificate. Functionally they serve the same web content — the difference is that 443 protects it in transit.

Is port 80 dangerous?

Port 80 itself is fine, but exposing plain HTTP on it is risky. Anything sent over it — credentials, cookies, form data — can be sniffed or tampered with, and the web application behind it is the single biggest attack surface on the host. Serve real content over HTTPS and keep port 80 for redirects only.

How do I close or block port 80?

Stop the HTTP listener or firewall TCP/80, but keep in mind most sites still need it: browsers hit port 80 first, and Let’s Encrypt’s HTTP-01 challenge renews certificates over it. The safer move is usually to leave 80 open for a 301 redirect and the ACME challenge, and serve all actual content over HTTPS. Rescan with nmap -p 80 <target> to confirm whatever you intended.

TL;DR

• Service: HTTP (unencrypted web traffic)
• Default port: 80/TCP
• Biggest risk: cleartext traffic plus the full web-app attack surface (SQLi, XSS, RCE off an old server banner)
• Mitigation: redirect to HTTPS with HSTS, patch the web server, disable risky methods, add security headers, firewall admin endpoints