December 11th, 2025

12 Ways to Secure API

Building securing APIs

In the age of data breaches & everything digital, there was never a lesser need to build secure APIs. Insecure APIs means:

1. Loss of private data
2. Financial Loss
3. Legal Implications
4. and many more.

Enough reasons to bring down a company. Let’s see how to secure an API. We will be using a simple use case and show you a few scenarios of how attackers think. At the end of this post, I also share my advice on simple ways to secure an API. Grab a coffee and read on.

A typical project could be like “I want to learn to drive”. Tasks could be to “contact a friend to accompany” and “contact a learning school” etc.

Assume below are some end points you are having:

1. localhost:9000/api/login
2. localhost:9000/api/logout
3. localhost:9000/api/profile
4. localhost:9000/api/user/password-reset
   1. It is also ok to use localhost:9000/api/user/password/reset
5. Delete a project (DELETE)
6. Create a task under a project (POST)
7. localhost:9000/api/project{id}/task/{taskId} –> Update or delete a task under a project (Put/Patch or Delete)
8. localhost:9000/api/project{id}/search?name=something&date=something –> Search for a task under a project (GET)

The unique id of the user who is submitting the requests & his/her token will be sent to the server via the HTTP headers.

Given this simple API, How do you go about securing your API? For that, you need to understand the “areas” where an attacker would fancy a chance. Let’s see what are the attacking points given a rest endpoint:

1. URL Path.
2. User Token.
3. Payload.
4. Query Strings.

Here we go

Let’s start by first logging into the application and grabbing the token. The token is either stored in a cookie, local storage or session storage. ( If you are not sure how to do it, ask a fellow developer. Take her/him to a coffee later)

Once you have the token, open Postman, start hitting the APIs and make it work – The regular flow (like how your UI calls). Once it’s working and you understand how Postman works, let’s start working on the actual testing which shows how secure our APIs are.

Data Setup

Here are some assumptions we will make (Just for this example). We will have two users ( User A and User B) who can create projects and tasks. All projects created by User A will start with the alphabet A only and User B projects will start with the alphabet B.

Given these, let’s see some examples of negative tests or white-box testing.

Scenario 1

Consider this URL to delete a project: http://localhost:9000/api/project/{projectId}

The real-world URL could be like this: http://localhost:9000/api/project/1 or http://localhost:9000/api/project/09abcf21

What to do?

Now try to change the {projectId} as suggested below and hit the API as User A:

1. Provide an Invalid projectId
2. Blank/Empty projectId
3. Valid projectId but the projectId belongs to User B.

Worse Case: You get a not-so-user-friendly error for the first two points. The third request deleted the project belonging to User B.
Best Case: Your server gives you a “Bad Request” or something similar for each of these attempts.

Scenario 2

Consider this URL to create a task under a project: http://localhost:9000/api/project/{projectId}/task

The real-world URL could be: http://localhost:9000/api/project/1/task or http://localhost:9000/api/project/09abcf21/task

What to do?

Now try to change the projectId as suggested below and hit the API as User A:

1. Invalid projectId
2. Blank/Empty projectId
3. Valid projectId but the projectId belongs to User B.

Worse Case: You get a not-so-user-friendly error for the first two points. The third request creates the task under the project belonging to User B.

Best Case: Your server gives you a “Bad Request” or something similar for each of these attempts.

Scenario 3

Consider resetting the password URL: http://localhost:9000/api/user/password-reset

What to do?

Now try to change the token as suggested below and hit the API as User A:

1. Invalid token
2. Blank/Empty token
3. Valid token but it belongs to User B.

Worse Case: You get a not-so-user-friendly error for the first two points. The third request resets User B’s password.

Best Case: Your server gives you a “Bad Request” or something similar for each of these attempts.

There are more
we have only shared a few common ones but this should excite you to find other ways to test the APIs and ensure they are secure. If you are a tester or a developer or a scrum master, give it a go and see how your application works. The you get into the “worse case scenario”, it is time to raise some bugs and inform the development team.

Here is my advice if you are an API developer:

1. Validate the token against the user using it.
2. Do not take the inputs from the browser as it is. Validate/polish it first.
3. Always have a Request/Response schema validator.
4. Do not send any secrets to frontend (API Keys, Passwords)
5. Make sure the error message does not give out any hints to hackers.
6. Follow Deny By Default or Principle of Least Privileges.
7. Implement Role Based Access Control for APIs
   1. Which role can do what
   2. Which role can access what resources
   3. Create the resources as a JSON or YAML and start working towards it
8. Have smart rate limiters
9. Traffic only via HTTPS
10. Perform an API risk assessment.
11. Do not put secrets in code – API Keys, Hashing keys etc.
12. Frustrate the attacker:
    1. Add delays
    2. Monitor and block IP addresses

Contact Evolvv today to enroll in one of our trending courses and future-proof your career!

Let’s Connect – Feel free to connect us on Instagram Telegram WhatsApp LinkedIn Facebook

Call on-
+91 6363-644-347 +91 8660-780-020
or email us-
evolvv@techvito.in