GET for POST

A request that was originally observed as a POST was also accepted as a GET. This issue does not represent a security weakness unto itself, however, it may facilitate simplification of other attacks. For example if the original POST is subject to Cross-Site Scripting (XSS), then this finding may indicate that a simplified (GET based) XSS may also be possible.

Accepting GET requests for operations originally designed for POST enables simplified exploitation of other vulnerabilities, particularly cross-site scripting and cross-site request forgery. GET requests expose parameters in URLs that are logged by web servers, proxies, and browser history, potentially leaking sensitive data. Attackers can embed malicious GET requests in images, links, or scripts that execute automatically when victims view attacker-controlled pages. This method bypass converts POST-only CSRF protections into trivially exploitable GET-based attacks that require no user interaction beyond visiting a malicious page.

Enforce strict HTTP method validation on the server side by rejecting GET requests for endpoints designed to accept POST. Implement method-specific routing that returns HTTP 405 Method Not Allowed for unsupported methods. For state-changing operations, authentication actions, and sensitive data submissions, require POST or other appropriate HTTP methods and reject GET entirely. Use web framework features that bind handlers to specific HTTP methods rather than accepting all methods by default. Verify that CSRF protections cannot be bypassed by switching from POST to GET requests.