2. Master the Basics, Break the Web: HTTP Fundamentals

1. HTTP Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD

HTTP methods define the type of action the client wants to perform on a resource. Each method has a specific purpose and is interpreted differently by servers, APIs, and security controls. Understanding them helps pentesters identify how data is handled and where manipulation is possible.

GET

Retrieves data from the server and sends parameters in the URL, making them visible in logs and browser history. Should not be used for sensitive operations.

• Easy to modify query parameters → useful for testing IDOR or info leaks.
• Example: GET /user?id=10 → change to id=11.

POST

Sends data in the request body, commonly used for logins, forms, and file uploads. More secure than GET but still fully interceptable.

• Great for testing input tampering, injections, and logic bypass.
• Example: POST /transfer amount=1000 → modify amount.

PUT

Replaces an entire resource with new data. Common in APIs for updating profiles or configurations.

• Weak access control may let attackers overwrite other users’ data.
• Example: PUT /api/user/10 with modified JSON.

DELETE

Removes a resource from the server. Highly sensitive and must be properly restricted.

• Poor authorization may allow deleting other users’ items.
• Example: DELETE /api/cart/5 → test with different IDs.

OPTIONS

Returns allowed HTTP methods for an endpoint. Used in CORS pre-flight checks and API discovery.

• Reveals hidden or unexpected methods (PUT, DELETE).
• Example: OPTIONS /api/user → shows Allow: GET, POST, PUT, DELETE.

HEAD

Same as GET but returns headers only — no response body. Useful for checking server info and metadata.

• Helps with recon and fingerprinting.
• Example: HEAD /index.html → inspect server headers.

2. Request & Response structure

A web request is how the client communicates with the server, and the response is how the server returns data. Both follow the HTTP format, containing a start line, headers, and an optional body. Understanding this structure helps pentesters modify, inject, and analyze how data flows through the application.

Request and Response

3. HTTP status codes (2xx, 3xx, 4xx, 5xx)

HTTP status codes indicate how the server processed a request. They help understand server behavior, errors, redirects, and access issues — all important for pentesting.

2xx — Success Codes

• 200 OK — Request succeeded, and the server returned the expected data. Useful in pentesting to confirm valid endpoints and proper behavior.
• 201 Created — Resource successfully created (common in APIs after POST or PUT). Important when testing object creation or access control after creation.
• 204 No Content — Request succeeded, but nothing is returned. Seen in deletions or silent updates.

3xx — Redirection Codes

• 301 Moved Permanently — Resource permanently moved to a new URL. Useful when checking for redirect chains or outdated endpoints.
• 302 Found — Temporary redirect — very common after login forms. It can be abused for open redirect vulnerabilities.
• 307 / 308 Redirect — Same as 302/301 but preserves the HTTP method. Important during API testing, where method changes matter.

4xx — Client Error Codes

• 400 Bad Request — Server cannot process malformed input. Pentesters can use this to test input validation and fuzzing.
• 401 Unauthorized — Authentication required or failed. Indicates missing tokens, bad credentials, or expired sessions.
• 403 Forbidden — Server understands the request but denies access. Key indicator in Broken Access Control testing.
• 404 Not Found — Resource does not exist. Useful for endpoint discovery and error-based recon.
• 429 Too Many Requests — Rate limiting triggered. Helps identify throttling protections or bypass opportunities.

5xx — Server Error Codes

• 500 Internal Server Error — Generic server failure — often caused by poor input handling. Can reveal stack traces or backend exceptions.
• 502 Bad Gateway — Upstream server failed (proxy, load balancer issues). Shows internal architecture during recon.
• 503 Service Unavailable — Service temporarily overloaded or down. Useful when testing DoS rate limits.
• 504 Gateway Timeout — Server didn’t respond in time. Exposes backend timeouts or slow endpoints.

4. HTTP Headers (Host, User-Agent, Referer, Accept, etc.)

HTTP headers carry metadata about the request and response. They tell the server how to process the request and provide details like client identity, accepted formats, cookies, and routing information. Manipulating headers is a core part of pentesting because many applications trust header values incorrectly.

Host Header

• Specifies the domain the client wants to reach and helps servers route the request.
• Pentest use: Can be abused for Host Header Injection, password reset poisoning, and cache manipulation.
  Example: Host: victim.com → change to Host: attacker.com.

User-Agent

• Tells the server what browser, OS, or tool the client is using.
• Pentest use: Can bypass simple filters or trigger log injection; also useful for WAF behavior testing.
  Example: User-Agent: CustomScanner/1.0

Referer (Referrer)

• Shows the page the user came from before making the request.
• Pentest use: Helps bypass weak CSRF checks and test navigation-based access control.
  Example: Referer: https://example.com/profile

Accept

• Indicates what formats the client can handle (HTML, JSON, XML, etc.).
• Pentest use: Helpful for forcing JSON/XML responses during API testing and injection scenarios.
  Example: Accept: application/json

Content-Type

• Describes the format of the data being sent in the request body.
• Pentest use: Changing this header can bypass validation or trigger vulnerabilities in file uploads or APIs.
  Example: Content-Type: application/json

Cookie

• Carries session tokens or login state information from the browser.
• Pentest use: Essential for testing session hijacking, fixation, and cookie security flags (HttpOnly, Secure).
  Example: Cookie: session=abcd1234

Authorization

• Contains credentials like API keys, tokens, or Basic Auth strings.
• Pentest use: Weak validation can allow privilege escalation or token reuse.
  Example: Authorization: Bearer <JWT>

X-Forwarded-For (XFF)

• Used by proxies to indicate the original client IP address.
• Pentest use: Often trusted incorrectly, making it possible to bypass IP restrictions or rate limits.
  Example: X-Forwarded-For: 127.0.0.1

Origin Header

• Indicates the domain where the request originated, mainly used in CORS and fetch/XHR requests.
• Pentest use: Key for testing CORS misconfigurations that can lead to data theft or cross-site attacks.
  Example: Origin: https://evil.com → used to test if the server incorrectly allows it.

5. Response Headers (Server, CSP, HSTS, Cache-Control, etc.)

Response headers are sent by the server to give the browser instructions on how to handle the response. They control security, caching, content behavior, and can reveal important info about the backend. For pentesters, analyzing these headers helps identify misconfigurations, missing protections, or leaked server details.

Server

• Shows information about the backend server (Apache, Nginx, IIS, etc.).
• Pentest use: Can expose versions or tech stacks that help identify vulnerabilities.
  Example: Server: Apache/2.4.29

Content-Security-Policy (CSP)

• Controls what content the browser is allowed to load (scripts, images, frames).
• Pentest use: A strong CSP helps prevent XSS; a weak one may allow payload execution.
  Example: Content-Security-Policy: script-src ‘self’

Strict-Transport-Security (HSTS)

• Forces the browser to use HTTPS only, preventing downgrade and MITM attacks.
• Pentest use: Missing HSTS can allow SSL stripping or insecure redirects.
  Example: Strict-Transport-Security: max-age=31536000; includeSubDomains

Cache-Control

• Defines how responses should be cached by browsers or proxies.
• Pentest use: Misconfigured caching can expose sensitive data to other users or shared systems.
  Example: Cache-Control: no-store, no-cache

Set-Cookie

• Controls session cookies and their security flags (HttpOnly, Secure, SameSite).
• Pentest use: Weak cookie flags allow session theft via XSS or MITM.
  Example: Set-Cookie: session=xyz; HttpOnly; Secure

Access-Control-Allow-Origin (CORS)

• Specifies which domains can access server resources via browser requests.
• Pentest use: A wildcard * or misconfigured allowed domains can lead to data theft.
  Example: Access-Control-Allow-Origin: https://trusted.com

X-Frame-Options

• Prevents the site from being loaded inside iframes.
• Pentest use: Protects against clickjacking; missing header increases risk.
  Example: X-Frame-Options: DENY

X-Content-Type-Options

• Stops browsers from MIME-type sniffing.
• Pentest use: Prevents content being interpreted incorrectly, blocking some XSS vectors.
  Example: X-Content-Type-Options: nosniff

Referrer-Policy

• Controls how much referrer information is shared when navigating.
• Pentest use: Weak policies may leak sensitive URLs or tokens in referrers.
  Example: Referrer-Policy: no-referrer

6. Understanding Query Parameters & Body

Query parameters and request bodies are the main ways a client sends data to a server. Query parameters appear in the URL, while the request body carries data inside POST/PUT/PATCH requests. Both are fully user-controlled and must be validated by the server.

Query Parameters

Query parameters are key–value pairs added to the URL after a ?. Used mainly for filtering, searching, sorting, pagination, and retrieving specific records. They are visible in logs, browser history, and easily modified.

Pentest Relevance:

• Highly vulnerable to IDOR, XSS, and injection attacks.
• Useful for fuzzing and discovering hidden functionality.
• Anything in the URL is user-controlled — never trusted.

💡Example: /product?id=25 → change id to test unauthorized access or data leakage.

Request Body

The body carries data inside the request, mainly in POST, PUT, PATCH, or DELETE requests. Used for login, updates, file uploads, form submissions, and API operations. Supports different formats: JSON, form-data, XML, raw text, etc.

Pentest Relevance:

• Most business logic and validation flaws appear here.
• Ideal attack surface for SQLi, NoSQLi, RCE, file upload bypasses, and logic manipulation.
• Content-Type changes can bypass input validation.

💡Example: POST body: {"username":"admin","isAdmin":false} → change "isAdmin":true to test privilege escalation.

Wrapping up here — next up: Cookies & Sessions

Catch you soon 🙌,
Abinesh