Overview
HTTP methods express what a request intends to do with a resource. In web security, understanding methods is essential because access control and safe design depend on how each method is meant to behave. This lesson covers methods from a security angle.
Learning objectives
- Recall the common HTTP methods and their intended semantics.
- Distinguish safe and idempotent methods.
- Explain the security implications of method usage.
Core concept
The common methods and their intended meaning:
- GET — retrieve a resource; should be safe (no state change).
- POST — submit data / create / trigger processing.
- PUT — replace a resource (idempotent).
- PATCH — partially update a resource.
- DELETE — remove a resource (idempotent).
- HEAD / OPTIONS — headers-only / capability discovery.
Safe = does not change state; idempotent = repeating it has the same effect as doing it once.
How it works
Well-designed applications honor these semantics: GET reads, DELETE removes, and so on. From a security view, the crucial rule is that state-changing actions should not be performed via GET, because GET requests are logged in URLs, cached, and easily triggered cross-site. Every method on a given endpoint must also be subject to the same access control — protecting GET but leaving DELETE open is a real flaw. OPTIONS can reveal which methods an endpoint allows.
Practical example
For a resource /api/users/42: GET reads it, PUT replaces it, DELETE removes it. If the app enforces "admin only" on the DELETE handler but forgot to protect PUT, an attacker could overwrite the user via PUT even though delete is blocked. Consistent authorization across all methods on the endpoint is required — a checkpoint testers examine directly.
Cybersecurity relevance
Methods matter for several web weaknesses: state-changing GETs enable CSRF-style abuse and leak data into logs/history; inconsistent access control across methods is a common broken-access-control finding; and dangerous methods (PUT/DELETE) unintentionally enabled on a server expand attack surface. During assessment, enumerating allowed methods (OPTIONS) and testing each method's authorization is standard practice.
Common mistakes
- Using GET for state-changing actions, exposing them to caching, logging, and CSRF.
- Protecting one method but not others on the same endpoint.
- Leaving dangerous methods enabled (PUT/DELETE) where they are not needed.
Key takeaways
- Common methods: GET (read/safe), POST (create/process), PUT (replace), PATCH (partial update), DELETE (remove), HEAD/OPTIONS (metadata/capabilities).
- Never perform state-changing actions via GET; apply consistent authorization across every method on an endpoint.
- Method misuse underlies CSRF exposure, broken access control, and unnecessary attack surface — all standard assessment checkpoints.
Check your understanding
- Why should a state-changing action never be exposed through a GET request?
- Why must access control be tested on every HTTP method an endpoint supports, not just one?