Web Application Basics

1. Web Application Overview#

A web application is a program that runs in a web browser. It is built from different parts that work together to give users an interactive experience.

Front End#

The Front End is what the user sees and interacts with in their browser. It includes:

• HTML (Hypertext Markup Language): The structure and content of the page. Tells the browser what to show.
• CSS (Cascading Style Sheets): The design and style. Controls colors, fonts, and layout.
• JavaScript (JS): Makes the page interactive. Adds dynamic behavior and logic.

Back End#

The Back End is what happens on the server. It is not visible to the user but is essential for the application to work. It includes:

• Web Server: Hosts the web application and handles requests.
• Database: Stores, retrieves, and manages data (like user preferences or content).
• Infrastructure: Networking, storage, and other systems that support the app.
• WAF (Web Application Firewall): Optional security layer that filters harmful requests and protects the app.

Summary#

A web application has:

• Front End: HTML, CSS, JavaScript (what users see and use).
• Back End: Server, Database, Infrastructure, WAF (what makes it work behind the scenes).

This is the basic overview. In the next sections, we will learn more about how these parts work together.

2. Uniform Resource Locator (URL)#

A Uniform Resource Locator (URL) is the web address you use to access content online. It tells your browser where to go to find things like web pages, videos, images, or other resources.

Anatomy of a URL#

A URL is made up of different parts. Each part has a specific role in helping you reach the right resource. Knowing these parts is useful for browsing, developing web apps, and troubleshooting.

1. Scheme

• Defines the protocol used.
• Common examples: http and https.
• HTTPS is secure because it encrypts the connection.

2. User

• Sometimes includes a username for login.
• Rare today because it’s insecure to share credentials in the URL.

3. Host / Domain

• The main part that identifies the website.
• Must be unique and is registered.
• Be cautious of fake domains (typosquatting) that look similar to real ones and are used in phishing.

4. Port

• Tells the browser which service to connect to on the server.
• Common ports:
  • 80 for HTTP
  • 443 for HTTPS

5. Path

• Points to a specific page or file on the server.
• Acts like a roadmap to the resource.
• Needs to be secured to limit access to authorized users only.

6. Query String

• Starts with a ? in the URL.
• Used for search terms or form inputs.
• User-controlled, so it must be validated to prevent attacks like injection.

7. Fragment

• Starts with #.
• Links to a specific part of a webpage (like a heading or section).
• User-controlled, so should be handled carefully.

3. HTTP Messages#

HTTP messages are the data packets exchanged between a user (client) and a web server. They are essential for understanding how web applications work because they define how requests and responses are sent and received.

Two Types of HTTP Messages#

1. HTTP Requests

   • Sent by the client (user) to the server.
   • Used to ask the server to do something (like loading a page or submitting a form).

2. HTTP Responses

   • Sent by the server back to the client.
   • Contains the result of the request (like a webpage, data, or status message).

Parts of an HTTP Message#

Each HTTP message has a standard format with these main parts:

1. Start Line

• The introduction of the message.
• For requests, it includes the method (e.g., GET, POST), URL, and HTTP version.
• For responses, it includes the HTTP version and a status code (e.g., 200 OK).

2. Headers

• Key-value pairs that give extra information about the message.
• Used for things like:
  • Content type
  • Security settings
  • Authorization
  • Cookies

3. Empty Line

• A required blank line.
• Separates the headers from the body.
• Helps the server and client know where the headers end and the body starts.

4. Body

• Contains the main content or data.
• In requests, this might be form data or JSON.
• In responses, this might be the HTML page, JSON data, images, etc.

Why Understanding HTTP Messages Matters#

• Foundation of Communication: HTTP messages make web communication possible between clients and servers.
• Debugging: Knowing the structure helps you find and fix issues.
• Security: Understanding how data is sent and received helps you protect it during transmission.

4. HTTP Request: Request Line and Methods#

An HTTP request is what a user (client) sends to a web server to ask it to do something. This is the first step in interacting with a web application.

Request Line#

The request line (also called the start line) is the first line in an HTTP request.
It tells the server what kind of request it is.

It has three main parts:

• Method (what action to do)
• URL Path (which resource)
• HTTP Version (protocol version)

Example:

GET /login HTTP/1.1

HTTP Methods#

HTTP methods describe what action the client wants the server to perform.
Here are the most common ones:

GET

• Retrieves data without changing anything.
• Watch out for exposing sensitive info in URLs.

POST

• Sends data to create or update something.
• Always validate inputs to prevent SQL injection or XSS.

PUT

• Updates or replaces a resource.
• Ensure the user is authorised before accepting changes.

DELETE

• Removes a resource.
• Authorisation is critical to prevent abuse.

PATCH

• Partially updates a resource.
• Validate data carefully to avoid inconsistencies.

HEAD

• Like GET but only fetches headers.
• Useful for checking metadata without downloading content.

OPTIONS

• Shows which methods are supported.
• Helps clients know what they can do.

TRACE

• Echoes the request for debugging.
• Often disabled for security reasons.

CONNECT

• Sets up a secure connection (like for HTTPS).
• Used for encrypted communication.

URL Path#

The URL Path tells the server which specific resource the client wants.
Example:

/api/users/123

• Always validate paths to avoid unauthorised access.
• Sanitise inputs to prevent injection attacks.
• Protect sensitive data through good security practices.

HTTP Version#

Specifies the HTTP protocol version used.

• HTTP/0.9 (1991): Very basic, only GET.
• HTTP/1.0 (1996): Added headers and better content support.
• HTTP/1.1 (1997): Persistent connections, better caching (still very common).
• HTTP/2 (2015): Faster, with multiplexing and header compression.
• HTTP/3 (2022): Uses QUIC for better speed and security.

Note:

• Many systems still use HTTP/1.1 for compatibility.
• Upgrading to HTTP/2 or HTTP/3 improves performance and security.

5. HTTP Request: Headers and Body#

An HTTP request has two main sections: headers and body.
These parts help the client (user) and server exchange detailed information.

Request Headers#

Headers are key-value pairs sent with the request.
They provide extra information about the request to the server.

Common Request Headers:

Request Body#

• The body carries the actual data sent to the server.
• Usually used with POST and PUT requests.
• Different formats can be used to send data.

Common Body Formats

1. URL Encoded

• Format: key=value pairs, separated by &.
• Used for simple form data.
• Content-Type: application/x-www-form-urlencoded.

Example:

name=Aleksandra&age=27&country=US

2. Form Data (Multipart)

• Used to send multiple blocks of data (including files).
• Each part is separated by a boundary string.
• Content-Type: multipart/form-data.

Example:

Content-Disposition: form-data; name="username"
 
aleksandra
 
Content-Disposition: form-data; name="profile_pic"; filename="aleksandra.jpg"
Content-Type: image/jpeg
 
[Binary Image Data]
 

3. JSON

• Structured as name-value pairs in JSON format.
• Easy to read and use in APIs.
• Content-Type: application/json.

Example:

{
    "name": "Aleksandra",
    "age": 27,
    "country": "US"
}

4. XML Uses opening and closing tags. Can represent nested data structures. Content-Type: application/xml.

Example:

<user>
    <name>Aleksandra</name>
    <age>27</age>
    <country>US</country>
</user>

6. HTTP Response: Status Line and Status Codes#

When you interact with a web application, the server sends back an HTTP response.
This tells you if your request was successful or if there was a problem.

Status Line#

The Status Line is the first line in every HTTP response.
It includes three parts:

• HTTP Version: The version of HTTP used.
• Status Code: A three-digit number that shows the result of your request.
• Reason Phrase: A short explanation of the status code.

Example:

HTTP/1.1 200 OK

Status Codes and Reason Phrases#

Status Codes tell you if the request succeeded or failed.
They are grouped into five main categories:

1️⃣ Informational Responses (100–199)

• Meaning: The server received part of the request and is waiting for the rest.
• Example:
  • 100 Continue – Ready for the rest of the request.

2️⃣ Successful Responses (200–299)

• Meaning: The request was successful.
• Example:
  • 200 OK – The server returns the requested resource.

3️⃣ Redirection Messages (300–399)

• Meaning: The resource has moved to a new location.
• Example:
  • 301 Moved Permanently – Use the new URL in future requests.

4️⃣ Client Error Responses (400–499)

• Meaning: There was a problem with the request.
• Example:
  • 404 Not Found – The server can't find the resource at the given URL.

5️⃣ Server Error Responses (500–599)

• Meaning: The server encountered an error.
• Example:
  • 500 Internal Server Error – Something went wrong on the server.

Common Status Codes#

Why Status Codes Matter#

• They help browsers and users understand what happened with a request.
• They guide developers in handling responses correctly.
• They are critical for debugging and security.

7. HTTP Response: Headers and Body#

When a web server responds to an HTTP request, it sends back HTTP response headers and an HTTP response body.
These parts help the client (browser) understand and handle the response properly.

Response Headers#

Response headers are key-value pairs that provide important information about the response.
They tell the browser how to process the data.

Required Response Headers

These headers are essential for proper communication:

• Date

  • Example: Date: Fri, 23 Aug 2024 10:43:21 GMT
  • Shows when the server generated the response.

• Content-Type

  • Example: Content-Type: text/html; charset=utf-8
  • Tells the client what type of content is being sent (HTML, JSON, etc.) and its character encoding.

• Server

  • Example: Server: nginx
  • Shows the server software handling the request.
  • Note: Can reveal information to attackers, so sometimes it’s hidden or modified.

Other Common Response Headers

These headers give extra instructions to the client:

• Set-Cookie

  • Example: Set-Cookie: sessionId=38af1337es7a8
  • Sends cookies from the server to the client.
  • Security tips: Use HttpOnly and Secure flags to protect cookies.

• Cache-Control

  • Example: Cache-Control: max-age=600
  • Tells the client how long it can cache the response.
  • Can prevent sensitive data from being cached with no-cache.

• Location

  • Example: Location: /index.html
  • Used in redirection (3xx status codes).
  • Tells the client where to go next.
  • Important: Validate and sanitise this header to avoid open redirect vulnerabilities.

Response Body#

The response body contains the actual content the server is sending back.
Examples of content:

• HTML pages
• JSON data
• Images
• Files

Security Note:

• Always sanitize and escape any user-generated content before including it in the response.
• This helps prevent attacks like Cr

8. Security Headers#

HTTP Security Headers improve the security of web applications.
They help protect against attacks like Cross-Site Scripting (XSS), clickjacking, and more.

You can test any website’s security headers using:
👉 securityheaders.io (opens in a new tab)

1️⃣ Content-Security-Policy (CSP)#

The CSP header is a security layer that helps prevent XSS attacks.
It tells browsers which sources of content are allowed.

Example: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.anas.com (opens in a new tab); style-src 'self'

Explanation:

• default-src 'self'
  • Only allows content from the same website.
• script-src 'self' https://cdn.tryhackme.com
  • Scripts can load from the site itself and the CDN.
• style-src 'self'
  • Stylesheets can only load from the site itself.

2️⃣ Strict-Transport-Security (HSTS)#

The HSTS header forces browsers to use HTTPS connections only.
Helps prevent downgrade attacks and ensures secure communication.

Example:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Explanation:

• max-age
  • Duration in seconds for enforcing HTTPS (here, 2 years).
• includeSubDomains
  • Applies HSTS to all subdomains.
• preload
  • Requests inclusion in browser preload lists to enforce HSTS even before first visit.

3️⃣ X-Content-Type-Options#

This header tells browsers not to guess content types, helping prevent MIME-type confusion attacks.

Example:

X-Content-Type-Options: nosniff

Explanation:

• nosniff
  • Forces the browser to use the declared Content-Type and not try to "sniff" or guess it.

4️⃣ Referrer-Policy#

Controls how much referrer information (the URL the user came from) is sent when navigating.

Examples:

Referrer-Policy: no-referrer
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
 

Explanation:

• no-referrer
  • No referrer info is sent.
• same-origin
  • Sends referrer only for links within the same site.
• strict-origin
  • Sends only the origin (domain) when protocol remains the same (HTTPS to HTTPS).
• strict-origin-when-cross-origin
  • Sends full referrer for same-origin requests; sends origin only for cross-origin.

Summary:
These security headers are essential tools for developers to reduce the risk of common web attacks and keep users safer.