HTTP is a wonderful thing: a protocol that has existed for more than 20 years without major changes.
This is the second part of a web security series: the first part was “How Browsers Work.”
As we saw in the previous article, browsers interact with web applications over HTTP, which is the main reason we are diving deeper into this topic. If users enter their credit card details on a website and an attacker intercepts that data before it reaches the server, we will definitely have a problem.
Understanding how HTTP works, how we can secure communication between clients and servers, and what security-related features the protocol provides is the first step toward improving our security.
When discussing HTTP, however, we must distinguish between semantics and technical implementation, as these are two very different aspects of how HTTP works.
A simple analogy explains this well: 20 years ago, people cared about their relatives just as they do now, even though the way they interact has changed significantly. Our parents might drive to visit family, while today we send messages via WhatsApp, call, or use social media. The nature of communication hasn’t changed — only the implementation.
HTTP is no different: its semantics have remained mostly the same, while its technical implementation has been optimized over time. If you look at an HTTP request from 1996, it will look very similar to modern ones, even though the way packets travel across the network has changed significantly.
---
Overview
HTTP follows a request/response model: a client sends a request to a server, and the server responds.
An HTTP message (request or response) consists of:
First line
Headers
Body
In a request, the first line specifies the method, the resource path, and the protocol version:
GET /players/lebron-james HTTP/1.1
Headers provide metadata in key-value form:
Host: nba.com
Accept: */*
Coolness: 9000
While custom headers can be used, it is recommended to follow standard HTTP headers. Deviating from standards may cause interoperability issues.
Custom headers are often prefixed (e.g., X-), though modern practice prefers names like Acme-Custom-Header.
The request may also include a body, separated by an empty line:
POST /players/lebron-james/comments HTTP/1.1
Best Player Ever
The body is optional and typically used when sending data.
---
HTTP Response
A response looks similar:
HTTP/1.1 200 OK
Content-Type: application/json
{"name": "Lebron James", "birthplace": "Akron, Ohio"}
It includes:
Protocol version
Status code
Headers
Optional body
---
HTTP vs HTTPS vs HTTP/2
HTTP has evolved with versions like 1.0 and 1.1.
HTTPS and HTTP/2 are mainly technical improvements:
HTTPS adds encryption and authentication
HTTP/2 (H2) improves performance
HTTP/2 introduces:
Binary protocol
Multiplexing
Header compression (HPACK)
---
HTTPS
HTTPS (HTTP Secure) uses TLS (Transport Layer Security).
It solves two main problems:
1. Authentication — verifying the identity of the server
2. Encryption — protecting data from interception
Servers present certificates, issued by trusted Certificate Authorities (CAs), to prove their identity.
Browsers verify these certificates and warn users if they are invalid.
---
Encryption
HTTPS establishes a shared secret key using algorithms like Diffie-Hellman.
Once established:
Communication is encrypted
Intercepted data cannot be read
---
HTTPS Everywhere
Modern browsers enforce HTTPS.
For example, Google Chrome marks HTTP sites as “Not Secure”, especially when users enter data.
This has made HTTPS the standard.
---
GET vs POST
HTTP methods include:
GET
POST
PUT
DELETE
Key differences:
GET
Data in URL
Idempotent
No side effects
POST
Data in body
Not idempotent
Can modify server state
---
Security Implications
Web servers log request URLs.
This means:
Sensitive data in URLs can be stored in logs
This is a major security risk
Headers and bodies are usually not logged, making them safer for sensitive data.
Thus:
POST is generally safer than GET
But security depends on how data is used, not just the method
---
Conclusion
HTTP provides a foundation for web communication, while HTTPS adds:
Authentication
Encryption
Together, they enable secure communication between clients and servers.
However, HTTP also offers many additional security mechanisms, especially through headers, which are explored further in web security practices.
This is the second part of a web security series: the first part was “How Browsers Work.”
As we saw in the previous article, browsers interact with web applications over HTTP, which is the main reason we are diving deeper into this topic. If users enter their credit card details on a website and an attacker intercepts that data before it reaches the server, we will definitely have a problem.
Understanding how HTTP works, how we can secure communication between clients and servers, and what security-related features the protocol provides is the first step toward improving our security.
When discussing HTTP, however, we must distinguish between semantics and technical implementation, as these are two very different aspects of how HTTP works.
A simple analogy explains this well: 20 years ago, people cared about their relatives just as they do now, even though the way they interact has changed significantly. Our parents might drive to visit family, while today we send messages via WhatsApp, call, or use social media. The nature of communication hasn’t changed — only the implementation.
HTTP is no different: its semantics have remained mostly the same, while its technical implementation has been optimized over time. If you look at an HTTP request from 1996, it will look very similar to modern ones, even though the way packets travel across the network has changed significantly.
---
Overview
HTTP follows a request/response model: a client sends a request to a server, and the server responds.
An HTTP message (request or response) consists of:
First line
Headers
Body
In a request, the first line specifies the method, the resource path, and the protocol version:
GET /players/lebron-james HTTP/1.1
Headers provide metadata in key-value form:
Host: nba.com
Accept: */*
Coolness: 9000
While custom headers can be used, it is recommended to follow standard HTTP headers. Deviating from standards may cause interoperability issues.
Custom headers are often prefixed (e.g., X-), though modern practice prefers names like Acme-Custom-Header.
The request may also include a body, separated by an empty line:
POST /players/lebron-james/comments HTTP/1.1
Best Player Ever
The body is optional and typically used when sending data.
---
HTTP Response
A response looks similar:
HTTP/1.1 200 OK
Content-Type: application/json
{"name": "Lebron James", "birthplace": "Akron, Ohio"}
It includes:
Protocol version
Status code
Headers
Optional body
---
HTTP vs HTTPS vs HTTP/2
HTTP has evolved with versions like 1.0 and 1.1.
HTTPS and HTTP/2 are mainly technical improvements:
HTTPS adds encryption and authentication
HTTP/2 (H2) improves performance
HTTP/2 introduces:
Binary protocol
Multiplexing
Header compression (HPACK)
---
HTTPS
HTTPS (HTTP Secure) uses TLS (Transport Layer Security).
It solves two main problems:
1. Authentication — verifying the identity of the server
2. Encryption — protecting data from interception
Servers present certificates, issued by trusted Certificate Authorities (CAs), to prove their identity.
Browsers verify these certificates and warn users if they are invalid.
---
Encryption
HTTPS establishes a shared secret key using algorithms like Diffie-Hellman.
Once established:
Communication is encrypted
Intercepted data cannot be read
---
HTTPS Everywhere
Modern browsers enforce HTTPS.
For example, Google Chrome marks HTTP sites as “Not Secure”, especially when users enter data.
This has made HTTPS the standard.
---
GET vs POST
HTTP methods include:
GET
POST
PUT
DELETE
Key differences:
GET
Data in URL
Idempotent
No side effects
POST
Data in body
Not idempotent
Can modify server state
---
Security Implications
Web servers log request URLs.
This means:
Sensitive data in URLs can be stored in logs
This is a major security risk
Headers and bodies are usually not logged, making them safer for sensitive data.
Thus:
POST is generally safer than GET
But security depends on how data is used, not just the method
---
Conclusion
HTTP provides a foundation for web communication, while HTTPS adds:
Authentication
Encryption
Together, they enable secure communication between clients and servers.
However, HTTP also offers many additional security mechanisms, especially through headers, which are explored further in web security practices.
