GET, POST, PUT, DELETE — the verbs of the web. Understand how browsers and APIs communicate, including headers, status codes, and security implications.
HyperText Transfer Protocol (HTTP) is the foundation of data communication on the web. Every time your browser loads a page, submits a form, or calls an API, it sends an HTTP request and receives an HTTP response. HTTP is a stateless protocol — each request is independent, with no memory of previous requests (cookies and sessions solve this).
HTTP operates at the Application Layer (Layer 7) of the OSI model. HTTPS is HTTP wrapped in TLS encryption — the data is the same, but the connection is encrypted so eavesdroppers can't read it.
HTTP methods (also called "verbs") define the type of action you want to perform on a resource. The method tells the server: "I want to GET this data," "I want to POST new data," or "I want to DELETE this resource."
Used every time you load a webpage, fetch an image, or call an
API to read data. Parameters are sent in the URL query string (?key=value). GET should never modify
data on the server. Since parameters are in the URL, sensitive data like passwords should
never be sent via GET.
Used when you submit a login form, create a new account, upload a file, or make a payment. Data is sent in the request body (not visible in the URL). Calling POST twice creates two resources — that's why duplicate form submissions are a problem.
Replaces the entire resource at the given URL. If you PUT a user object, you must include all fields — any omitted fields are set to null/default. Sending the same PUT twice always produces the same result.
Deletes the resource at the specified URL. Idempotent: deleting the same resource twice returns 200/204 the first time, 404 the second time — but the end state (resource gone) is the same.
Unlike PUT, PATCH only modifies the specified fields. If you want to change just a user's email without sending the entire object, use PATCH. More bandwidth-efficient for large resources.
Returns only the response headers. Used to check if a resource
exists, get its size (Content-Length), or check
modification time (Last-Modified) without downloading
the full content. Useful for link checkers, caching logic, and monitoring.
Every HTTP response includes a status code — a 3-digit number that tells the client what happened. Understanding these codes is essential for debugging, security testing, and API development.
200 OK — Request succeeded, data returned201 Created — New resource created (POST response)
204 No Content — Success but no body (DELETE response)
301 Moved Permanently — Resource moved, update your
bookmarks302 Found — Temporary redirect (common in login flows)
304 Not Modified — Cached version is still valid400 Bad Request — Malformed request syntax401 Unauthorized — Authentication required403 Forbidden — Authenticated but no permission404 Not Found — Resource doesn't exist429 Too Many Requests — Rate limited500 Internal Server Error — Generic server crash502 Bad Gateway — Upstream server failed503 Service Unavailable — Server overloaded/maintenance
418 I'm a Teapot is a real status code defined in RFC 2324 as an April
Fools' joke. Google's teapot page (google.com/teapot) still returns it!
curl is the command-line tool every
developer and pentester uses to make HTTP requests. Here are examples for each method:
Every HTTP request consists of three parts: the request line (method + path + version), headers (metadata key-value pairs), and an optional body (data payload for POST/PUT/PATCH). Here's a real-world example:
The server then responds with a status line (e.g.,
HTTP/1.1 200 OK), response headers (Content-Type, Set-Cookie,
Cache-Control), and a response body (HTML, JSON, image, etc.).
CORS is a security mechanism that controls which domains can make requests to your API. By default, browsers block requests from a different origin (domain, port, or protocol) — this is the Same-Origin Policy.
To allow cross-origin requests, the server must include CORS headers in its response:
⚠️ Security Warning: Setting Access-Control-Allow-Origin: * allows any website to make requests to
your API — avoid this for authenticated endpoints.
Security headers are your first line of defense against common web attacks. These are set by the server in HTTP responses and instruct the browser on how to handle the content securely.
Content-Security-Policy (CSP)
Specifies which sources of content (scripts, styles, images) are allowed to load. Prevents XSS attacks by blocking inline scripts and unauthorized external scripts.
Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com
Strict-Transport-Security (HSTS)
Forces the browser to only use HTTPS for this domain. Prevents SSL stripping attacks (downgrade from HTTPS to HTTP). Once set, the browser won't even attempt HTTP.
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options
Controls whether the page can be loaded in an <iframe>. Prevents clickjacking attacks
where an attacker overlays a transparent iframe over a legitimate page.
X-Frame-Options: DENY
Set-Cookie Flags
HttpOnly: Cookie can't be accessed by JavaScript (prevents XSS cookie theft). Secure: Cookie only sent over HTTPS. SameSite: Prevents CSRF by restricting cross-site cookie sending.
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict
X-Content-Type-Options
Prevents the browser from "sniffing" the content type and interpreting files differently than declared. Stops attackers from uploading a malicious HTML file disguised as an image.
X-Content-Type-Options: nosniff
Referrer-Policy
Controls how much referrer information is sent when
navigating from your site to another. Prevents leaking sensitive URLs (e.g., /admin/users/42) to third parties.
Referrer-Policy: strict-origin-when-cross-origin
Understanding these vulnerabilities is crucial for both offensive security (finding bugs) and defensive security (protecting applications):
An attacker creates a malicious page that includes a
hidden form or image tag that triggers a request to a target site. If the user is logged in,
their browser automatically sends cookies, making the request look legitimate. Example: A
hidden image tag <img src="https://bank.com/transfer?to=attacker&amount=10000">
could trigger a money transfer.
Defense: CSRF tokens (unique per-session token embedded in forms), SameSite cookie attribute, checking the Referer/Origin headers.
When an API uses predictable identifiers (like sequential
IDs) without proper authorization checks. An attacker changes /api/users/42 to /api/users/43 to access another user's data. One
of the most common and easiest-to-exploit vulnerabilities in APIs.
Defense: Always verify the authenticated user has permission to access the requested resource. Use UUIDs instead of sequential IDs. Implement proper authorization middleware.
Some servers only check authorization for specific
methods. An attacker might discover that while GET /admin
returns 403 Forbidden, changing the method to OPTIONS, HEAD, or even a non-standard method
might bypass the restriction.
Defense: Enforce method whitelisting per endpoint, apply authorization checks uniformly across all HTTP methods.
Exploits differences in how front-end (load balancer) and back-end servers parse HTTP requests. By crafting ambiguous Content-Length and Transfer-Encoding headers, an attacker can "smuggle" a second request inside the first, potentially bypassing security controls or poisoning caches.
Defense: Use HTTP/2 end-to-end, normalize request parsing, reject ambiguous requests.
Build HTTP requests like a pro. Select a method, enter a path, and hit Send to see the mock server response.
All certification names are referenced for educational purposes only. This project is not affiliated with any certification body.