Why HTTP Is Insecure and How to Defend Against Common Web Attacks

1. Transmitting Passwords Over HTTP Without HTTPS

HTTP is a plain‑text protocol, so credentials sent over it can be intercepted. One mitigation is to use asymmetric encryption: the server provides a public key to the browser via JavaScript, the client encrypts the password, and the server decrypts it with the corresponding private key. Servers should generate key pairs dynamically and recycle them via a limited‑size key pool.

2. File‑Path Traversal Attacks

Many operating systems use ".." to refer to the parent directory. If an attacker includes ".." in a URL and the server does not properly sanitize the path, the attacker can access files outside the intended directory, potentially reaching the root and reading any file. Servers typically block ".." in URLs and monitor logs for such patterns.

3. DNS Spoofing

Web requests rely on DNS to resolve domain names to IP addresses. A malicious DNS provider can return an incorrect IP, directing users to a phishing site that captures sensitive information.

4. Risks of Using External HTTP Proxies

An HTTP proxy sits between the client and the server and can act as a man‑in‑the‑middle, modifying responses, leaking data, or performing phishing attacks similar to DNS spoofing.

5. 413 Request Entity Too Large

The server returns a 413 error when a client uploads a file that exceeds the server’s size limit.

6. 414 Request‑URI Too Long

The server returns a 414 error when the requested URI exceeds the allowed length.

7. 202 Accepted

This status code is used for asynchronous requests; the server acknowledges receipt and may provide an endpoint for the client to poll for progress.

8. POST Data Submission Methods

Three common content types are used when sending data via POST:

application/x-www-form-urlencoded – key/value pairs encoded in the request body.

application/json – a JSON string, often used by APIs such as Elasticsearch.

multipart/form-data – used for file uploads and mixed form data.

POST http://example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
a=1&b=2&c=3&c=4

POST http://example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"a":1,"b":2,"c":[3,4]}

<form action="http://example.com/upload" method="post" enctype="multipart/form-data">
  <input type="text" name="key1" value="value1">
  <input type="text" name="key2" value="value2">
  <input type="file" name="file1">
  <input type="file" name="file2">
  <button type="submit">Submit</button>
</form>

9. Cookies

Cookies often carry session identifiers. The server stores session data, which may include sensitive permissions. If an attacker obtains the cookie, they can impersonate the user. Mitigations include binding sessions to client IP/UA and using HTTPS.

10. Important Cookie Attributes

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

The Secure flag ensures the cookie is sent only over HTTPS, while HttpOnly prevents JavaScript from accessing the cookie.

11. CSRF (Cross‑Site Request Forgery)

CSRF tricks a logged‑in user into sending a state‑changing request (e.g., deleting a blog post) by embedding a malicious link or form. Defenses include using POST for modifications and embedding a server‑generated CSRF token in forms.

# Delete article with ID 123456
http://example.com/blog/123456/delete

12. XSS (Cross‑Site Scripting)

If an attacker can inject arbitrary JavaScript into a page, they can steal cookies, perform actions on behalf of the user, or load malicious scripts.

<div>
  # User content start
  <script>send_to_hacker(document.cookie)</script>
  # User content end
</div>

13. Cross‑Origin Issues

Browsers block cross‑origin requests for security reasons. An attacker can open a malicious site that reads data from a victim’s authenticated site via the victim’s cookies, leading to data leakage.

14. JSONP (JSON Padding)

JSONP uses a <script> tag to request data from another domain. The server wraps the response in a callback function, allowing the client to execute the data without cookies, which mitigates CSRF but only supports GET.

function some_callback(data) {
    console.log(data)
}
<script src="http://example.com/someapi?callback=some_callback"></script>

15. CORS (Cross‑Origin Resource Sharing)

CORS enables browsers to make cross‑origin AJAX requests. Simple requests (GET/HEAD/POST with limited headers) are allowed if the server includes Access-Control-Allow-Origin. Complex requests trigger a pre‑flight OPTIONS request, adding latency but providing finer control.