DEV Community

Cover image for Security dangers when dealing with API parameters
Isaac Boampongsem
Isaac Boampongsem

Posted on

Security dangers when dealing with API parameters

API parameters are the keys and values an API endpoint accepts to manipulate the API response.

For instance, when dealing with an API endpoint for sign-ups, username, email, and password are the keys(parameters) and the values will be the user's input that the endpoint may accept.

An API is meant to be consumed by front-end developers and applications, how they consume it or deal with a particular endpoint in the front-end application can pose security dangers or vulnerabilities in the whole application.

API endpoints can be consumed in 2 forms, and it's either you pass the keys and values to the Params or the Body, with a GET, POST, PUT, DELETE, etc method.
When keys and values are passed to an endpoint through the Params, the keys, and values are added to the API endpoint URL before sending it to the server, while when the keys and values are passed through the Body, it doesn't cause any change to the API endpoint URL before sending it to the server.

With the above explanation, we should practically know what type of endpoints we can manipulate by passing the keys and values through the Params, and the ones we can manipulate by passing the keys and values through the Body.

For instance, going back to our sign-up endpoint example, the endpoint accepts username, email, and password as its keys and values or parameters. This endpoint is requesting sensitive user data and as such passing the keys and values through the Params can cause a security vulnerability in your application.

Therefore, it is generally not recommended to send sensitive information like signup, login, and card credentials to their endpoints through query parameters (params) in the URL.

Since query parameters are visible in the URL, they can easily be intercepted and logged by various systems, which include web servers, proxies, and browser history. This action can pose a significant security risk, especially for sensitive data like passwords.

Here are other reasons sensitive keys and values shouldn't be passed through query parameters(params):

  1. The Visibility: As pointed out, the query parameters which are the keys and values are visible in the URL, which means anyone who gets access to the URL via browser history, or network logs can see any sensitive data that was passed by the user. An example of an API endpoint URL and parameters is below;
http://example.com/api/login?username=John_user&password=12345678
Enter fullscreen mode Exit fullscreen mode

This can be very dangerous when a user's sensitive data is exposed.

  1. The Security Risks: As stated in point one, query parameters are mostly logged in various systems, such as web server logs, proxy logs, and browser history. When sensitive information is stored in these logs it can be exposed to unauthorized access. Attackers can use the user's credentials to log in to the application.

  2. The Caching mechanisms: Some caching mechanisms may cache API endpoint URLs with query parameters and the success response, by potentially exposing sensitive data in the cached responses.

Hence, it is recommended that endpoints that take up sensitive data be passed through the request Body (e.g., in a POST request) to transmit sensitive information securely. For instance, when a user is signing up or logging in, the keys and values should be passed through the request's Body using a secure protocol like HTTPS.

Here's an example of how you may want to structure a sign-up request using the request body in JSON format:

POST https://example.com/api/sign-up
Content-Type: application/json

{
    "username": "John_user",
    "email": "johnuser@example.com",
    "password": "secure_password"
}
Enter fullscreen mode Exit fullscreen mode

Using the body of the request ensures that sensitive information is not made visible to attackers in the URL or other logs and is transmitted securely over HTTPS.

That's a wrap. Thanks for reading to the end. Feel free to follow and leave a comment.

Top comments (0)