HTTP POST is an HTTP request method used to send data to a server, usually to create a resource, submit a form, or trigger processing. The request places the payload in the message body, and servers may treat repeated POSTs as non-idempotent operations.
How HTTP POST Works
HTTP POST is the request method browsers, apps, and APIs use when the client needs to send data in the message body rather than in the URL. That makes it the usual choice for form submission, record creation, and other actions that carry a payload to the server.
The method is defined by its semantics, not by a particular application pattern. A POST request can carry many content types, and the server decides how to interpret the body, validate it, and produce a response.
Why POST Is Different From Read-Only Requests
POST is commonly contrasted with GET because it is intended for operations that change state or initiate processing. In practice, that means POST is often used where the server creates something new, records an event, starts a workflow, or performs a calculation that depends on submitted input.
Because POST is not inherently idempotent, repeating the same request may create duplicate records or trigger the same action more than once. That property is one reason APIs often separate POST from methods used for safe retrieval.
State Change, Idempotency, and Reliability
The non-idempotent nature of POST is operationally important. If a client retries after a timeout, the server may accept the request twice unless the application has its own deduplication, transaction handling, or idempotency controls.
That is why many production systems treat POST as a state-changing event that needs careful handling at the application layer, especially when the action affects billing, account state, task submission, or object creation.
Where POST Fits In Web and API Design
POST is a core mechanism for browser forms, service integrations, and modern APIs because it supports structured payloads and server-side processing without exposing submitted data in the URL. It is therefore a foundational method in application design, not just a legacy web form feature.
Designers typically choose POST when they want the server to own the resulting state transition and when the request body is the natural place for the input data. The method itself does not guarantee safety, validation, or access control, those properties must be implemented separately by the application.
Risk and Threat Considerations
POST can carry sensitive or high-impact actions, so weaknesses in validation, authorisation, replay handling, or transport protection can turn an ordinary request into an abuse path. It is also a frequent target for automated submission, injection into server-side workflows, and duplicate-action problems when retry logic is not bounded.
Failure mechanism: Attackers or buggy clients can submit malformed payloads, replay requests, or trigger unguarded state changes when the server trusts POST content without sufficient validation, anti-replay handling, or access checks.
Impact: The result can be duplicate transactions, unwanted object creation, workflow abuse, data corruption, or exposure of sensitive business processes through an endpoint that was assumed to be routine.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | POST is a basic web service request pattern that must be validated at the API layer. |
| Recommendation — Validate POST request handling, including input checks and service-side enforcement, for API endpoints. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | POST often drives state-changing business flows that can be abused if not protected. |
| Recommendation — Protect POST-driven business flows with explicit authorization and abuse-resistant controls. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | POST endpoints often perform actions that require server-side access enforcement. |
| SI-10 — Information Input Validation | POST bodies carry input that must be validated before processing. | |
| AU-2 — Event Logging | POST submissions to sensitive workflows should be logged for traceability and review. | |
| Recommendation — Enforce access decisions on POST requests before allowing state-changing actions. Validate POST payloads before the server processes them. Log significant POST events so state changes can be investigated and correlated. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | POST endpoints that change state depend on access control at the application boundary. |
| Recommendation — Apply access control to POST endpoints that perform protected actions. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | POST actions should be limited to authorised users and processes. |
| Recommendation — Restrict POST-capable actions to approved accounts and services. | ||
Practitioner Guidance
What to watch for: Treat POST endpoints as state-changing interfaces and design them with explicit ownership, validation, and observability. That matters most when the same request might be retried by clients, gateways, or load balancers, because the application must decide whether a repeated submission is a harmless retry or a second real action.
Practitioner takeaway: The method choice is only the starting point; the real security and reliability properties come from how the server handles payloads, retries, and side effects.