So I work on many projects where I notice that some implementations of APIs are poorly done prior to my arrival, and a lot of time refactoring has to be done, so I decided to put few items that need to be considered when you are building your APIs. This information is also useful if you are going into an interview and need to have a solid conversation about POST vs GET.
Things to Consider:
- HTTP POST requests supply additional data from the client (browser) to the server in the message body. In contrast, GET requests include all required data in the URL.
- When the method is GET, all form data is encoded into the URL, appended to the action URL as query string parameters. With POST, form data appears within the message body of the HTTP request.
- Form data being sent as part of the URL is that one can bookmark the URLs and directly use them and completely bypass the form-filling process.
- All form data filled in is visible in the URL. Moreover, it is also stored in the user's web browsing history/logs for the browser. These issues make GET less secure.
- If the form data set is large - say, hundreds of characters - then METHOD="GET" may cause practical problems with implementations which cannot handle that long URLs.
GET vs POST:
| GET | POST | |
|---|---|---|
| Security | GET is less secure compared to POST because data sent is part of the URL. So it's saved in browser history and server logs in plaintext. | POST is safer than GET because the parameters are not stored in browser history or in web server logs. |
| Usability | GET method should not be used when sending passwords or other sensitive information. | POST method used when sending passwords or other sensitive information. |
| Visibility | GET method is visible to everyone (it will be displayed in the browser's address bar) and has limits on the amount of information to send. | POST method variables are not displayed in the URL. |
| Hacked | Easier to hack for script kiddies | More difficult to hack |
| Caching | Can be cached | Not cached |
| Restrictions | Yes, only ASCII characters allowed. | No restrictions. Binary data is also allowed. |
| History | Parameters remain in browser history because they are part of the URL | Parameters are not saved in browser history. |
What are some of the most common API security best practices?
- Use Tokens - Establish trusted identities and then control access to services and resources by using tokens assigned to those identities.
- Use Encrypted signatures - Encrypt your data using a method like TLS. Require signatures to ensure that the right users are decrypting and modifying your data, and no one else.
- Quotas and Throttling - Place quotas on how often your API can be called and track its use over history. More calls on an API may indicate that it is being abused. It could also be a programming mistake such as calling the API in an endless loop. Make rules for throttling to protect your APIs from spikes and Denial-of-Service attacks.
- Use an API gateway - API gateways act as the major point of enforcement for API traffic. A good gateway will allow you to authenticate traffic as well as control and analyze how your APIs are used.
References:
- Citibank Case: (https://www.apisec.ai/what-made-citis-hack-much-worse-how-to-avoid-the-same-mistake/)
- API Security: (https://www.redhat.com/en/topics/security/api-security)
- HTTP Methods (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST)
- GET vs POST: (https://www.diffen.com/difference/GET-vs-POST-HTTP-Requests)
- C# Web API: (https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client)
- Photo Credit Scott Webb on Unsplash
Top comments (0)