HTTP Security: A Security-focused Introduction to HTTP, Part 1

This is the first part in a two part series on HTTP security and HTTP basics. In this first part we bring you overview of the HTTP protocol.

HTTP is a ubiquitous protocol and is one of the cornerstones of the web. If you are a newcomer to web application security, a sound knowledge of the HTTP protocol will make your life easier when interpreting findings by automated security tools, and it’s a necessity if you want to take such findings further with manual testing. What follows is a security-focused introduction to the HTTP protocol to help you get started.

HTTP overview

HTTP is a message-based (request, response), stateless protocol comprised of headers (key-value pairs) and an optional body. Three versions of HTTP have been released so far — HTTP/1.0 (released in 1996, rare usage), HTTP 1.1 (released in 1997, wide usage) and HTTP/2 (released in 2015, increasing usage).

The HTTP protocol works over the Transmission Control Protocol (TCP). TCP is one of the core protocols within the Internet protocol suite and it provides a reliable, ordered, and error-checked delivery of a stream of data, making it ideal for HTTP. The default port for HTTP is 80, or 443 if you’re using HTTPS (an extension of the HTTP over TLS).

HTTP is a line-based protocol, meaning that each header is represented on its own line, with each line ending in a Carriage Return Line Feed (CRLF) with a blank line separating the head from the optional body of the request or response.

Up to HTTP/1.1, HTTP was a text-based protocol, however, with HTTP/2 this has changed — HTTP/2, unlike its predecessors is a binary protocol with most implementations requiring TLS encryption. It’s worth noting that for the vast majority of cases (and certainly, for this article) interacting with the HTTP/2 protocol won’t be any different. It’s also worth mentioning that HTTP/1.1 isn’t going away anytime soon, and it’s still early days for HTTP/2 (as such, HTTP/1.1 will be referenced throughout this article).

HTTP requests

In order to initiate an HTTP request, a client first establishes a TCP connection to a specified server on a specified port (80 or 443 by default).

The request would start with an initial line known as a request line which contains a method (GET in the following example, more on this later), a URL (/, indicating the “root” of the host in the below example) and the HTTP version (HTTP/1.1 in the below example). We must also include a Host header in order to tell the HTTP client where to send this request.

GET / HTTP/1.1

The above is exactly what a browser does when you type in into its URL bar. If we wanted to get the contents of, we would send the following request instead.

GET /about.html HTTP/1.1

HTTP Request Methods

The HTTP protocol defines a number of HTTP request methods (sometimes also referred to as verbs), which are used within HTTP requests to indicate to the server a desired action for a particular resource.

GETThe GET method is used to retrieve a resource from a server.
POSTThe POST method is used to submit data to a resource.
TRACEThe TRACE method is used to echo back anything sent by the client. This HTTP method is typically abused for reflected Cross-site Scripting (XSS).
PATCHThe PATCH method is used to apply partial updates to a resource.
PUTThe PUT method is used to replace a resource.
HEADThe HEAD method is used to retrieve a resource identical to that of a GET request, but without the response body.
DELETEThe DELETE method is used to delete the specified resource.
OPTIONSThe OPTIONS method is used to describe the supported HTTP methods for a resource.
CONNECTThe CONNECT method is used to establish a tunnel to the server specified by the target resource (used by HTTP proxies and HTTPS).

HTTP Responses

On the server side, an HTTP server listening on port 80, sends back an HTTP response to the client for what it has requested.

The HTTP response will contain a status line as the first line in a response, followed by response. The status line indicates the version of the protocol, the status code (200 in the below example), and, usually, a description of that status code.

Additionally, the server’s HTTP response will typically also include response headers (Content-Type in the below example) as well as an optional body (with a blank line at the end of the head of the request).

HTTP/1.1 200 OK
Content-Type: text/html


Response status codes

HTTP response status codes are issued by the server within an HTTP response to let the client know what the status of the request is. Status codes are organized in the following categories.

Status code groupDescription
4xxClient error
5xxServer error

Some of the most relevant HTTP status codes for web application security testing are the following, however, a full list of status codes and their description may be found here.

Status code groupDescription
200 OKIndicates that the request has succeeded.
301 Moved PermanentlyIndicates that the resource requested has been permanently moved to the URL within the Location response header.
302 Found (Temporary Redirect)Indicates that the resource requested has been permanently moved to the URL within the Location response header.
400 Bad RequestIndicates that the server could not understand the request by the client, usually due to invalid syntax
401 UnauthorizedIndicates the request could not be served due to insufficient authentication.
403 ForbiddenIndicates that the server understood the request but refuses to authorize it.
404 Not FoundIndicates that the server can not find the requested resource.
405 Method Not AllowedIndicates that the request method is known by the server, but it is not allowed to be used with this resource.
500 Internal Server ErrorIndicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

In the second part of this series, we’ll be covering several attributes of the HTTP protocol such as encoding, HTTP headers and authentication in more detail.

*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by acunetix. Read the original post at: