: Why clients might send unsanctioned requests (i.e. where did this POST come from?) I've been building web apps for awhile, and while I'm quite aware that this is the Internet and your server

@Kimberly868

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.

Vote Up Vote Down