PaperlayerView exact revision on arXiv

Source-linked AI summary

When POST Becomes GET: Investigating HTTP Method Interchangeability and Its Security Implications

Matteo Golinelli, Seif Errahmane Hannachi, Bruno Crispo

arXiv:2610.37474v1cs.CR

TL;DR

Applications do not always enforce the distinction between safe GET retrieval and potentially state-changing POST operations, leaving limited evidence about how often requests behave equivalently across methods. The paper presents MIDE, a browser-based measurement pipeline, and finds high-confidence interchangeability across the unauthenticated Tranco top 10k, alongside method-scoped defense gaps and cacheability conditions.

  • Problem

    HTTP method semantics distinguish safe retrieval from operations that may change state, but deployed applications may not enforce this boundary consistently.

    Source: §1 · p. 1

  • Method

    MIDE crawls applications in a browser, rewrites supported POST bodies as GET query strings, and compares responses against the POST and a no-query GET baseline.

    Source: §1 · p. 2

  • Results

    407 sites showed high-confidence interchangeability: 4.1% of tested sites, 12.7% of sites with captured POSTs, and 14.9% of sites with replayed POSTs.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The measurements identify method-scoped defense gaps and cacheability conditions, without proving state changes, sensitive-data exposure, or end-to-end exploitability.

    Source: §7 · p. 9

    The unauthenticated crawl, page and interaction caps, and synthetic inputs constrain results to the POST surface reached by that interaction strategy.

    Source: Limitations · p. 11

Abstract

from arXiv · show

HTTP method semantics are a common boundary between safe retrieval and state-changing operations; however, deployed web applications do not always enforce this boundary consistently. In this paper, we study HTTP method interchangeability, a behavior where a POST request can be rewritten as a GET request to the same endpoint, with POST body parameters moved into the query string, while preserving an equivalent observed response. We present Method Interchange Detection Engine (MIDE), an automated pipeline that crawls web applications in a browser, records POST requests generated by page loads and user-interface interactions, converts supported POST bodies into GET candidates, and compares replayed responses with the original POST response. To avoid counting generic or parameter-independent responses as interchangeable, MIDE also sends a no-query GET baseline. We treat as high-confidence evidence of interchangeability only the cases where the converted GET matches the POST, while the baseline does not. We perform a large-scale unauthenticated experiment on the Tranco top 10k. We find high-confidence interchangeable requests on 407 of 10,000 tested sites (4.1%), 407 of 3,200 sites with captured POSTs (12.7%), and 407 of 2,734 sites with replayed POSTs (14.9%). A targeted Cross-Site Request Forgery (CSRF) token-replay check finds cases where invalid tokens are rejected for POST but accepted for the equivalent GET. We also observe Web Cache Deception (WCD) conditions and cacheable GET responses for interchangeable request instances. These results demonstrate that method interchangeability is observable in real web applications and can expose method-scoped defense gaps.

1. Introduction

HTTP method semantics distinguish safe retrieval from potentially state-changing operations, yet applications may process POST and GET requests equivalently. The paper introduces MIDE to measure this behavior and examine its prevalence and security implications.

1. Introduction

  • The study focuses on rewriting browser-observed POST requests to the same endpoint as GET requests, moving body parameters into the query string and comparing responses.Equivalent responses alone do not establish state change or data leakage, though they expose request forms that may challenge assumptions made by defenses, caches, routing middleware, or application code.Source: §1 · p. 1
  • MIDE crawls with a browser, converts supported POST bodies into GET query strings, and compares replayed responses using a no-query GET baseline.It counts high-confidence interchangeability only when the converted GET matches the POST and the baseline does not; its code and configuration are released as open source.Source: §1 · pp. 1–2
  • 407 sites showed high-confidence interchangeability: 4.1% of tested sites, 12.7% of sites with captured POSTs, and 14.9% of sites with replayed POSTs.The unauthenticated Tranco top 10k experiment also found 646 of 8,291 replayed routes (7.8%) and 1,228 of 14,244 replayed requests (8.6%) affected.Source: §1 · p. 2
  • The paper analyzes framework and API-technology patterns, including unified parameter access, routing constraints, and array-parameter parsing, that may enable or constrain interchangeability.It reports that popular technologies exhibit behaviors that can lead to method interchangeability.Source: §1 · p. 2
  • The study identifies cases where invalid CSRF tokens are rejected for POST but accepted for equivalent GET, and tests interchangeable GET URLs for cacheability.The study frames these as method-scoped defense gaps and cacheability conditions, not proof of state changes or sensitive-data exposure.Source: §1 · pp. 1–2

1.1. Research Questions

  • The paper asks whether framework and API patterns enable interchangeability, whether it can be detected automatically at scale, how prevalent it is, and what security implications follow.The experiment evaluates the methodology on the Tranco top 10k.Source: §1 · p. 1, §1.1 · p. 2

2. Background

The background explains how HTTP method interchangeability arises when applications process different methods equivalently despite differing method semantics. It connects this behavior to assumptions underlying CSRF defenses and web caching.

2.1. Method Interchangeability

  • GET is intended for safe, idempotent operations, while POST may create or modify server-side state; application abstractions and routing can blur this distinction.Frameworks may merge query and body parameters, while client-side behavior can also contribute to interchangeable requests.Source: §2.1 · pp. 2–3
  • Method interchangeability means a server processes requests with different methods in semantically equivalent ways; it is not inherently a vulnerability but can expose alternative request forms to defenses.The background describes shared handlers, permissive routing, and intermediaries that normalize or rewrite requests as possible contributors.Source: §2.1 · pp. 2–3

2.2. Cross-Site Request Forgery

  • CSRF defenses commonly apply tokens or origin checks to unsafe methods while treating GET as safe, so a state-changing endpoint reachable via GET may receive cross-site authentication cookies.Method interchangeability can make such requests easier to trigger cross-site, including through a link or embedded resource; the background also discusses login CSRF and session fixation.Source: §2.2 · p. 3

2.3. Web Cache Deception

  • Web Cache Deception occurs when a cache stores and serves a response intended as dynamic and user-specific, due to differing origin and cache interpretations of a URL.Interchangeability can make responses otherwise served through POST accessible via GET, which may be cacheable.Source: §2.3 · p. 4

3. Related Work

Related work situates method interchangeability among research on HTTP method semantics, parameter parsing, CSRF, caching, and inconsistent security-policy interpretation. The paper presents its focus as a distinct phenomenon without prior systematic measurement.

3. Related Work

  • The authors report no prior systematic measurement of HTTP method interchangeability as a distinct phenomenon.They connect their study to established lines of web-security research.Source: §3 · p. 4

HTTP Method Semantics and Verb Tampering.

  • HTTP assigns safety and cacheability properties to methods, while security testing guidance covers verb tampering and method-based access-control bypasses.The cited guidance also discusses method-override headers such as X-HTTP-Method-Override,.Source: HTTP Method Semantics and Verb Tampering · p. 4

Parameter-Source and Parser Inconsistencies.

  • Balduzzi et al. studied HTTP Parameter Pollution, where attackers exploit differences in parsing duplicated or encoded parameters.Their work treats parameter location and parsing rules as security-relevant when components disagree about precedence or interpretation.Source: Parameter-Source and Parser… · p. 4

CSRF and Method-Scoped Defenses.

  • Prior CSRF work includes robust defense analysis, automated detection using dynamic analysis and property graphs, and supervised learning to identify sensitive requests for black-box testing.Other cited work studies deployment, effectiveness, and limitations of SameSite cookies.Source: CSRF and Method-Scoped Defenses · p. 4

WCD and Cache Inconsistencies.

  • Prior WCD research introduced the attack pattern,, studied its prevalence and path confusion, and expanded detection with response-identicality checks and cache-status heuristics.Golinelli et al. examined how hidden web caches can be difficult to observe when cache-status headers are absent or unreliable.Source: WCD and Cache Inconsistencies · p. 4

Semantic and Policy Inconsistencies on the Web.

  • Work on framing and security-policy inconsistencies shows that divergent interpretation across components or pages can produce different protection guarantees,.The authors view method interchangeability as another instance of this broader phenomenon.Source: Semantic and Policy Inconsistencies on… · p. 4

4. Method Interchangeability in Popular Web Frameworks

The framework analysis examines how routing, parameter access, and API specifications shape method interchangeability. It finds that both parameter-source abstractions and route reachability matter, while some API technologies intentionally permit GET and POST for read-only operations.

4. Method Interchangeability in Popular Web Frameworks

  • The analysis compares server-side designs across seven ecosystems, examining parameter access, routing defaults, and array parsing through documentation review and test applications.Its goal is to characterize design patterns and conventions, not to identify inherent framework flaws or vulnerabilities.Source: §4 · p. 5

4.1. Method Interchangeability in API Interface Technologies

  • GraphQL query operations must be accepted via POST and may also be accepted via GET, while mutations must not execute via GET; SPARQL similarly permits either method for queries but reserves POST for updates.OData distinguishes side-effect-free functions invoked via GET from actions invoked via POST; JSON:API, gRPC, and XML-RPC use method-specific semantics, while JSON-RPC leaves interchange to implementations.Source: §4.1 · p. 5

4.2. Framework Analysis Summary

  • Interchangeability depends on parameter-source abstraction and route reachability: permissive routing combined with unified or partly unified input handling is more prone to it.Vanilla PHP and some Spring MVC or ASP.NET Core configurations fit that pattern; several other frameworks require explicit multi-method routing, while Django, Express, FastAPI, NestJS, Next.js, and SvelteKit keep parameter sources more explicit. GraphQL and SPARQL intentionally allow GET/POST duality for read-only operations.Source: §4.2 · p. 5

5. Methodology

The methodology uses browser-observed POST requests to test whether equivalent GET requests can be identified without mistaking generic responses for interchangeability. MIDE combines realistic request collection, body conversion and replay, and baseline-controlled response comparison.

5.1. System Overview

  • MIDE separates browser collection from request conversion and replay, allowing conversion strategies or equivalence thresholds to change without recrawling sites.The large-scale measurement uses an unauthenticated browser context.Source: §5 · p. 5, §5.1 · p. 6

5.2. Crawling and Request Collection

  • The crawler captures POSTs from page loads and user actions, including forms and selected controls, while filtering potentially destructive or state-changing actions.It also skips file uploads and generates benign, syntactically valid form inputs rather than attack payloads.Source: §5.2 · p. 6

5.3. Method Interchange Detection Engine (MIDE)

  • MIDE converts supported POST bodies into GET query candidates, replays each converted GET and a no-query baseline, and removes body-specific headers.It supports form-urlencoded, multipart fields, and bounded-depth JSON; file parts and some JSON values or structures can make conversions lossy or fail.Source: §5.3 · p. 6

5.4. Response Equivalence Analysis

  • The comparator tolerates non-essential response differences, such as timestamps and dynamic identifiers, by comparing structure rather than requiring exact matches.The captured bodies are not normalized before scoring, and manual inspection checks sampled positive and negative classifications without defining the headline class-A measurement.Source: §5.4 · p. 7
  • Response equivalence requires matching status codes and structural similarity of at least 0.95, with format-specific comparisons and vetoes for conflicting JSON outcome fields.Class A is high-confidence interchangeability: the converted GET matches the POST, but the no-query GET does not; classes A and B form a broader upper bound.Source: §5.4 · p. 7

5.5. Design Rationale

  • MIDE’s conservative detection identifies equivalent observed responses, not exploitability; security consequences depend on endpoint semantics and surrounding defenses.The no-query control helps prevent generic responses from being counted as strong evidence.Source: §5.5 · p. 7

6. Experiment

The unauthenticated Tranco experiment measures high-confidence method interchangeability across sites, routes, and replayed requests. Baseline controls filter apparent equivalences, while manual checks, conversion analysis, and endpoint labels characterize the measurement and its limits.

6.1. Analysis Population

  • 2,887 captured POSTs (13.6%) were clean equivalent replay candidates, while unsupported or unknown content types accounted for 5,641 (26.5%).The 21,280 captured POST records came from 3,200 sites; captured POST totals are a lower bound because potentially destructive actions and file uploads were filtered.Source: §6.1 · p. 7, Table 1 · p. 8

6.2. Baseline-Control Classes

  • 1,782 of 3,010 requests in classes A and B (59.2%) were ambiguous because the no-query GET also matched the POST; class A contained 1,228 high-confidence requests.Without the baseline control, the ambiguous cases would also appear interchangeable.Source: §6.2 · p. 8, Table 2 · p. 8

6.1. Analysis Population

  • 407 sites—4.1% of 10,000 tested, 12.7% of 3,200 with captured POSTs, and 14.9% of 2,734 with replayed POSTs—had a high-confidence interchangeable request.The measurement was conducted without authentication.Source: §6 · p. 7, Table 3 · p. 8, §6.1 · p. 8

6.3. Comparator Validation and Sensitivity

  • In manual review of 60 sampled replay records (30 class-A positives, 30 class-D negatives), all 30 class-A converted GET responses were judged equivalent to POST responses, giving an observed class-A precision of 100%; none of 30 usable class-D records was judged equivalent.Source: §6.3 · p. 8

6.4. Prevalence

  • Prevalence is reported at site, route, and request levels, distinguishing affected sites from unique routes and individual replayed POST instances.The denominators are 10,000 tested sites, 8,291 unique replayed routes, and 14,244 replayed POST records.Source: §6.1 · p. 7, §6.4 · p. 8

6.5. Conversion and Replay Failures

  • JSON conversion succeeded for 6,231 of 7,570 records (82.3%), compared with 7,310 of 7,310 form-urlencoded records; multipart conversion succeeded for 703 of 759 (92.6%).JSON produced 1,389 lossy conversions, while the captured multipart bodies were fields-only.Source: §6.5 · pp. 8–9

6.6. Endpoint Taxonomy

  • Search or filtering was the largest heuristic label among high-confidence requests, with 379 requests (30.9%); labels are broad signals, not confirmed endpoint functionality.The unauthenticated measurement cannot establish user-dependent cross-origin leakage for such endpoints.Source: §6.6 · p. 9

7. Security Implications of HTTP Method Interchangeability

The paper examines whether interchangeable GET requests expose gaps in defenses that rely on HTTP method semantics. Token replay finds method-specific validation differences, and cache testing identifies payload-induced and already-cacheable GET responses, without establishing end-to-end exploitability.

7. Security Implications of HTTP Method Interchangeability

  • The measurements identify method-scoped defense gaps and cacheability conditions, but do not establish state changes, sensitive-data exposure, or end-to-end exploitability.The analysis focuses on CSRF and Web Cache Deception.Source: §7 · p. 9

7.1. CSRF Token Validation Gaps

  • Seven candidates across two sites showed a method-specific token gap: POSTs with missing or changed tokens were rejected, while corresponding converted GETs remained equivalent to successful POST responses.The targeted analysis selected 115 token-bearing candidates across 46 sites; 78 candidates across 25 sites accepted invalid tokens for both methods.Source: §7.1 · pp. 9–10
  • These observations indicate that a POST token check may not apply to an equivalent GET, but the study did not verify state change, user-specific sensitivity, or cross-site triggerability.The results are evidence of method-scoped defense gaps, not confirmed end-to-end CSRF exploits.Source: §7.1 · p. 10

7.2. WCD Cacheability Conditions

  • Among 1,228 high-confidence request instances across 407 sites, 56 (4.6%) had a payload-induced WCD-style cache hit, while 136 (11.1%) were already cacheable at the original converted GET URL.Each instance was counted once by its strongest outcome across 12 payloads; site counts are non-exclusive.Source: §7.2 · p. 10, Table 7 · p. 10
  • Method interchangeability can expose POST-equivalent dynamic responses through cacheable GET URLs, including responses already cacheable without a WCD payload.The study also observed payload-induced cache hits.Source: §7.2 · p. 10

8. Discussion

In the Tranco top 10k, high-confidence method interchangeability appeared on 4.1% of tested sites, with measured CSRF token-validation gaps and cacheable GET responses. The discussion also qualifies these findings as bounded by the crawler’s unauthenticated, selective interaction and request-conversion coverage.

8. Discussion

  • 4.1% of tested sites, 12.7% of sites with captured POSTs, and 14.9% of sites with replayed POSTs had a high-confidence interchangeable request.The behavior affected 646 of 8,291 replayed routes (7.8%) and 1,228 of 14,244 replayed requests (8.6%).Source: §8 · pp. 10–11
  • 1,782 replayed requests were ambiguous class-B cases, versus 1,228 high-confidence class-A cases, suggesting the high-confidence estimate may understate interchangeability.Class-B endpoints returned equivalent responses even after converted parameters were removed.Source: §8 · p. 11
  • 387 high-confidence interchangeable requests (31.5%) received potentially security-relevant taxonomy labels, and 121 (9.9%) were labeled API or RPC endpoints.The heuristic labels identify follow-up areas such as authentication, profile updates, and account settings, but do not establish authenticated access.Source: §8 · p. 11
  • Among 115 token-bearing requests, seven cases across two sites accepted invalid CSRF tokens via GET after rejecting them via POST; cache checks also found payload-induced hits and already-cacheable GETs.The cache observations covered 56 request instances across 9 sites with payload-induced hits and 136 instances across 50 sites already cacheable at the converted GET URL.Source: §8 · p. 11

Limitations

  • The crawler’s denylist excludes potentially destructive or state- and session-changing actions and file uploads, making the collected POST population a lower bound.The measurement is unauthenticated and therefore omits functionality available only after login.Source: Limitations · p. 11
  • Headless-browser behavior and bot detection may prevent observation of pages, controls, or requests and bias the measured population toward sites permitting automated access.Client characteristics such as user agent, network access method, and language settings can produce inconsistent client-side security policies.Source: Limitations · p. 11
  • Replay covers supported body formats only; lossy conversions and the 8,192-byte query-length limit exclude some requests, making prevalence conservative for the explored population.Servers and intermediaries may enforce different URL limits.Source: Limitations · p. 11

8.1. Conclusion

  • The conclusion presents MIDE as a browser-based POST-to-GET response-equivalence measurement pipeline and reports that equivalent GETs can expose token-validation gaps and cacheable responses.The authors release the code and experimental configuration as open source.Source: §8.1 · p. 11

Ethical Considerations

The crawler was configured to limit its impact on visited sites, using bounded browsing and interaction, benign inputs, and safeguards against destructive or sensitive actions.

Ethical Considerations

  • The Tranco crawl was bounded to 10 pages and depth 5, stopped after 100 captured POSTs per site, and processed sites sequentially with a 5-second delay.Per page, it interacted with at most 5 forms and 10 standalone buttons.Source: Ethical Considerations · p. 11
  • The crawler used benign synthetic inputs, skipped file inputs, and did not inject malicious payloads.It interacted with at most 5 forms and 10 standalone buttons per page.Source: Ethical Considerations · p. 11
  • Safeguards excluded potentially destructive or state- and session-changing actions, denylisted URLs, and multipart requests containing file uploads.Replay sent only converted GET requests and rate-limited them with a 2-second delay between records.Source: Ethical Considerations · p. 11

LLM Usage Statement

The authors used Claude Sonnet 4 and OpenAI models for implementation assistance and editorial work, while retaining responsibility for the research design and conclusions.

LLM Usage Statement

Appendix A. Detailed Web Framework Analysis

The appendix compares how web frameworks unify parameter access, constrain routes by method, and parse array-like parameters. These differences matter because POST-to-GET transformations must preserve semantic equivalence under framework-specific parsing rules.

A.1. Unified Parameter Access

  • Flask, Rails, Sinatra, PHP, and Laravel provide forms of unified parameter access, while Spring MVC, ASP.NET Core, and Gin offer partial or adaptive unification.Django, Express, FastAPI, NestJS, Next.js, and SvelteKit keep query parameters and request bodies more explicit.Source: §A.1 · p. 13

A.2. Routing and Method Constraints

  • Unified parameter access alone does not imply method interchange; the endpoint must also be reachable through multiple HTTP methods.Source: §A.2 · p. 13
  • Vanilla PHP scripts are generally reachable through any method unless the application checks the request method, and $_REQUEST combines query and POST inputs.Source: §A.2 · p. 13
  • Spring MVC generic mappings and ASP.NET Core generic routes may accept multiple methods unless narrowed, while Django views are method-permissive but keep request sources explicit.Laravel, Flask, Rails, Sinatra, and Gin require explicit developer action for multi-method reachability.Source: §A.2 · p. 13

A.3. Array Parameter Parsing

  • These parsing differences shape automated detection because POST-to-GET transformations must preserve semantic equivalence under framework-specific rules.Source: §A.3 · p. 13
  • Frameworks differ in array parsing: Spring accepts repeated keys, PHP supports PHP-style and indexed arrays, Flask supports repeated keys, and Rails and Sinatra support multiple encodings.Rails and Sinatra may interpret indexed arrays as maps rather than true arrays.Source: §A.3 · p. 13

Appendix B. Reasons for Missed Replays and Equivalences

Appendix B quantifies why captured POSTs did not yield clean equivalent replays, highlighting conversion constraints and the complexity of JSON request bodies.

Appendix B. Reasons for Missed Replays and Equivalences

  • 10,414 captured POSTs (48.9%) were converted and replayed but did not produce responses equivalent to the POST response.Before applying the no-query baseline, 3,010 replayed POSTs produced an equivalent converted GET response.Source: Appendix B · p. 14
  • 2,887 captured POSTs (13.6%) were clean equivalent replay candidates, while 123 other equivalent responses had empty bodies or exceeded the query threshold.The 123 comprised 109 empty POST bodies and 14 conversions exceeding 8,192 bytes.Source: Appendix B · p. 14
  • Unsupported content types accounted for 5,641 captured POSTs (26.5%), while 465 conversions exceeded the configured 8,192-byte query threshold.The 465 comprised 197 form-urlencoded, 255 JSON, and 13 multipart conversions; their 95th-percentile query lengths were 3,536, 6,133, and 5,372 bytes, respectively.Source: Appendix B · p. 14
  • Among 7,570 captured JSON POST records, 60.1% contained nested objects and 28.5% nested arrays, alongside 4.6% body parse errors.Labels were non-exclusive; 89.6% were top-level objects, while top-level arrays, mixed arrays, and scalar JSON were less common.Source: Appendix B · p. 14
Loading 2610.37474v1…