The belief that a request using a read-only method or route cannot cause state change. Modern APIs can violate that assumption if validation and execution are decoupled, so the method alone is not a sufficient security boundary.
What the Read-Only Transport Assumption Actually Means
The read-only transport assumption is a shortcut many teams make when designing or reviewing APIs: if a request uses a safe-looking method or route, it is assumed incapable of changing server state. That assumption is about transport semantics, not about business logic.
In practice, the method label is only one signal. Whether a request can mutate data depends on what the server does after routing, including validation, side effects, deferred execution, queueing, stored procedures, and downstream service calls.
Why the Assumption Breaks in Modern API Designs
Modern systems often separate request handling from execution. A read-only endpoint can still trigger asynchronous work, write audit records, update caches, enqueue jobs, or call another component that performs a state change. The transport method may remain read-only while the system outcome is not.
That gap is why method-level trust is fragile. A security review that stops at the HTTP verb can miss the actual trust boundary, especially when a gateway, API layer, and application service each enforce different checks.
Security Implications of Treating Read-Only as Safe
When teams equate “read-only” with “no impact,” they can under-estimate abuse paths such as data tampering through side effects, privilege confusion, cache poisoning, or hidden write operations behind apparently harmless requests. This is especially relevant in APIs where object access, function execution, and business workflow triggers are exposed through the same interface.
Design reviews should therefore focus on what the request can cause, not only on how it is labelled. OWASP API Security Top 10 remains a useful reference point for the broader class of authorization, exposure, and unsafe API behaviour that can arise when interfaces are trusted too early.
How to Reason About Read-Only Methods and Side Effects
A safer mental model is to treat transport method as a convention, not a control. The real question is whether the request path can influence state anywhere in the execution chain, including validation rules, downstream integrations, caching layers, logging pipelines, and background workers.
That reasoning also means distinguishing visible response semantics from hidden system effects. A request can return a read-only response while still changing authorization state, workflow status, telemetry, or third-party records. In other words, “read-only” should describe intention, not guarantee safety.