I've been building web apps for awhile, and while I'm quite aware that this is the Internet and your server has to be ready for anything, by and large humans using browsers make the HTTP requests you expect them to make.

I find it hard to explain, then, why particular unsanctioned calls show up again and again. For instance, I have one endpoint, /api/organizations/<id> which accepts GET requests, but not POST requests. Yet certain clients will commonly POST to that endpoint. Why might that be the case?

I want to understand my users better and make sure I'm not making any important mistakes. I've reviewed my client side code and I'm fairly certain it's not my javascript making the request.


To be clear, this is not a reproducible error. Trying to use the app with a browser with a matching user agent does NOT make the unsanctioned call. The pattern suggests a very small set of individuals generating the calls with some idiosyncratic local setup.

  • These may not be made by actual people. Bots, scrapers, hackers, and the like are a possibility. Check the IP address so see if it is a subscriber IP address, meaning an actual phone company. Otherwise, you may want to consider either blocking the requests or redirecting a POST to a GET.
    – closetnoc
    Mar 20, 2017 at 22:38
  • Are they submitting 'legitimate' data? In the past I have been mischievous and created a form that will submit to another site and then had a cron job run it (it was to jam a phishing site with noise submissions and make it hard to find the real suckers)
    – Steve
    Mar 21, 2017 at 6:41
  • Yeah, an automatically inserted form on the page, like through some plugin, had crossed my mind.
    – Chris
    Mar 21, 2017 at 13:36

1 Answer 1


I've previously come across HTTP 301/302 redirects changing a POST request to a GET request but not the other way around. While unlikely, it's possible that a:

(a) proxy server in use by one of your users that is not compliant with IETF standards is inadvertently or deliberately changing the HTTP method type;

(b) a malicious bot may be probing for vulnerabilities or sending you junk data just so you can enjoy the spam experience upon the assumption it might be a contact form that sends you an email or something like that;

(c) something/anything else? It's hard to tell without seeing example POST data and server logs to establish any patterns in timing/geography etc.

However I believe it's far more likely that it could be the mistake of a developer who has customised their API integration and simply not yet realised. In this circumstance if you wish to minimise server workload and ensure developers understand the POST method is not supported, in addition to making this clear in your API documentation, when POST requests come into your API you could respond with an HTTP header that indicated the method is not allowed:

HTTP/1.0 405 Method Not Allowed

If you wish to know more about the end-user of your API then you could make it so that your API requires authentication. They login to your website and supply some basic details about themselves and why they use your API, agree to terms and conditions of use etc and then you enable their API access. Their first call would need to be a POST request to an authentication API with their username and password to which you return a unique authenticated session token or serial number which they must supply as a header to subsequent API GET requests. From any valid API request after making this change you would be able to identify and contact the end-user. In response to GET requests sent without a valid authenticated session token you could send the header:

HTTP/1.0 401 Unauthorized

Any prolonged repeated HTTP 401s and 405s from the same IP address should probably be added to a blacklist to which your firewall can just drop the connections without any HTTP response.

  • "redirects changing a POST request to a GET" - any 301 or 302 will do that.
    – MrWhite
    Mar 29, 2017 at 14:02
  • @w3dk That's what I meant in my first sentence, in this case however Chris was asking what might cause the opposite - GET requests to be changed to POST requests. I'll update my answer to include the redirect codes. Mar 29, 2017 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.