Cybersecurity glossary
What is an HTTP Method?
Learn what an HTTP method is, how GET, POST, PUT, PATCH, and DELETE differ, which methods are safe or idempotent, and how method misuse creates security bugs.
Definition
An HTTP method (also called an HTTP verb) is the request semantic that tells a server what action the client wants to perform on the target resource—such as retrieve (GET), create or process (POST), replace (PUT), partially update (PATCH), or delete (DELETE).
Why HTTP methods matter
URLs name resources; HTTP methods name intents. A well-designed API lets operators, caches, browsers, and security tools predict whether a request is a read, a write, or a metadata probe.
When teams overload GET with deletions or treat every action as POST, caches break, CSRF risk rises, and authorization reviews become guesswork.
Common methods and their intent
| Method | Typical intent | Common properties |
|---|---|---|
| GET | Retrieve a representation | Safe, idempotent, cacheable when rules allow |
| HEAD | Like GET but headers only | Safe, idempotent |
| POST | Process input; often create or trigger actions | Not safe; not idempotent by default |
| PUT | Create/replace a resource at a known target | Idempotent when implemented correctly |
| PATCH | Apply a partial update | Not inherently idempotent |
| DELETE | Remove the target resource | Idempotent when repeated deletes agree |
| OPTIONS | Discover allowed methods/headers | Safe; used heavily in CORS |
How a method is processed
Client chooses method and target
The request line carries the verb and path or URL identifying the resource.
Intermediaries apply method-aware rules
Caches, CDNs, and WAFs treat safe reads differently from state-changing writes.
Server routes by method
Frameworks match route + verb; unsupported methods should return 405 with Allow.
Authz checks the action
Permission is often action-specific: read vs update vs delete on the same object.
Handler executes semantics
Business logic must honor safety and idempotency expectations for that verb.
Status code reports the outcome
2xx/3xx/4xx/5xx communicate success, redirection, client error, or server failure.
Safety, idempotency, and cacheability
Safe methods
Should be read-only. Using GET for state changes invites crawlers and prefetch bugs.
Idempotent methods
Repeating the same request should yield the same server-side effect as doing it once.
Cacheable responses
GET/HEAD are the usual candidates; correct Cache-Control still required.
CSRF and cookies
Browser-sent cookies make state-changing methods a CSRF target without tokens or SameSite.
Security pitfalls
Method override tricks
Headers like X-HTTP-Method-Override can bypass proxies that only filter POST/GET—disable if unused.
Verb confusion in authz
Allowing GET but forgetting DELETE on the same ID is a classic access-control gap.
TRACE and debug methods
Disable dangerous or unnecessary methods on production edge servers.
Body on GET
Some clients send bodies on GET; many intermediaries ignore them—do not rely on that pattern.
Practical checklist
- Map each API operation to a method that matches its safety and idempotency story.
- Return 405 Method Not Allowed with an Allow header when a verb is unsupported.
- Protect cookie-authenticated state changes against CSRF.
- Authorize per method and per object—not only per URL path.
- Disable method override headers unless you have a documented need.
- Rate-limit costly POST/PUT/PATCH/DELETE more tightly than public GETs when appropriate.
- Document whether PUT creates resources and whether DELETE is idempotent in your API.
- Verify caches and CDNs never cache authenticated or unsafe responses incorrectly.
The practical takeaway
An HTTP method expresses the intended action on a resource. Choosing the right verb helps caches, browsers, and humans understand risk—and keeps APIs predictable.
Treat methods as part of your security contract: keep reads safe, make repeated writes idempotent where promised, authorize every verb explicitly, and never hide dangerous actions behind GET.
Related security terms
HTTP Status Code
The response counterpart that reports how the method was handled.
Idempotency
A property expected of methods like GET, PUT, and DELETE when implemented correctly.
Representational State Transfer (REST)
An API style that maps resource operations to HTTP methods.
Cross-Site Request Forgery (CSRF)
An attack that tricks browsers into issuing unwanted state-changing methods.
Rate Limiting
Often applied differently to read methods versus costly write methods.
Frequently asked questions
What is an HTTP method in simple terms?
It is the action word at the start of an HTTP request—like GET to read or DELETE to remove—so the server knows what you want done.
What are the most common methods?
GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS cover most web and API traffic. Others exist (TRACE, CONNECT) with narrower uses.
Is POST always for creating resources?
Not always. POST means “process this data according to the resource’s rules.” Creation is common, but so are searches, actions, and RPC-like endpoints.
What is the difference between PUT and PATCH?
PUT typically replaces the target resource representation. PATCH applies a partial update. Exact behavior should be documented by the API.
Which methods are safe?
Safe methods (notably GET and HEAD) should not change server state. They may still be abused for side effects if developers misuse them.
Can I use GET for deleting something?
You can technically, but you should not. Prefetchers, crawlers, and CSRF-like patterns may trigger GETs unintentionally.
What does OPTIONS do?
It asks which methods and headers are allowed—often used in CORS preflight checks before a cross-origin request.
References
Explore authoritative guidance and frameworks related to http method.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.