7 Tips for Designing Secure REST APIs

Sharing is Caring

REST APIs are stateless APIs used to access and manipulate data using common operations. Making a robust and secure API requires following best practices and providing a uniform interface.

Why is Security important?

Businesses use APIs to connect services and transfer data – so a hacked API could lead to a data breach or a loss of efficiency while the team tries to resolve the problem.

Broken, exposed or hacked APIs could expose all sorts of sensitive information for public consumption.

Cybercriminals are increasingly targeting APIs. API security is important and crucial to the modern enterprise.

Security is all about understanding the tradeoffs you are making – every bit of complexity added makes it harder for users to see value from your API.

Tip 1: Use proper Authentication (Don’t allow Basic Auth!)

Basic Authentication (sending the username + password) repeatedly for every request isn’t a great security practice. There’s a number of reason’s it’s not a great practice:

  • Password is sent over the internet in every request as a base64 encoded string – basically plaintext.
  • The password could be cached by the web browser and potentially be reused in a Cross Site Reforgery Request (CSRF).

SSL helps some, but it doesn’t help if it there’s any internal routing or server logging that could potentially see the plaintext password.

Use a common authentication method – API Keys, JSON Web Tokens, or oAuth.

Tip 2: Never include sensitive information in the URI

Never expose delicate information, like usernames, passwords, API keys etc., in URIs. It used to be a common practice to use a query string with an api key in it – this isn’t secure. It’s not very difficult to see these requests on the network and then be able to make the same requests.

Tip 3: Use HTTPS

Using HTTPs allows the server and client to use end-to-end encryption. End to end encryption makes it far more difficult for a malicious party to observe and decrypt the data that is being sent.

If a client is a web site and it connects to your API through JavaScript in the front end it will fail in most modern browsers because HTTPS and HTTP communication and generally blocked.

HTTPs doesn’t have to cost much, most cloud providers provide free SSL certificates. Let’s Encrypt is also a great option for a free SSL certificate.

Unencrypted communication over HTTP allows for simple eavesdropping and impersonation.

Tip 4: Validate all user input

All user input whether it’s in the Header, URI or in the body should be validated. Strong validation should check for issues and reject requests immediately if there are any concerns.

Input validation stops improperly formed data from entering the system, and stops a lot of malicious attacks. Malicious attacks that could be stopped are things like an injection attack, memory leak, compromising the system, etc.

I always start by assuming all data from outside of the system is coming from an untrusted source. I don’t care if it’s from a supplier, partner, vendor, a government, or a user – it’s not yet validated and trusted.

I like to use a JSON Schema or XML Schema (XSD) input validation. In Node.js – I tend to use Avj for JSON Schema. I try to avoid XML, so I haven’t used any libraries in Node.js.

Tip 5: Always validate that the Access Token is valid and has permission

If the access token is expired, you should be returning a 401 Unauthorized error. If the user has an authenticated token but doesn’t have the permissions to access the resource we should be returning a 403 Forbidden.

So often, I see APIs that have an authorizer or authorization check that just checks that the token isn’t expired yet by looking at the expiration date in the token. What if I needed to remove that user for some reason?

Tip 6: Use CORs

CORS stands for Cross-Origin Resource Sharing. CORs allows you to whitelist requests to a web server from certain locations. It’s specified in a response header with a key of “Access-Control-Allow-Origin” and a value of what is allowed.

CORs allows us to control who can access the API from the frontend which helps us potentially manage risk.

Tip 7: Never return a stack trace

When an unexpected error occurs you should never return a stack trace. Instead return a 500 internal server error and log it. If you are using a cloud provider, make sure that you are alerted when 500 errors are sent out.

Error messages should always be clear to your users event when unexpected things have happened.

Bonus Tip 1: Pay attention to the OWASP Top 10

Every year, the OWASP organization creates a document from developers and IT professionals discussing the critical security risks to web applications. Adopting these principles allows us to produce more secure systems.

OWASP also provides a number of automated tests that can be used to run against projects too. You can access the Top 10 Risks at: https://owasp.org/Top10/

Wrapping it Up

Security is all about understanding the tradeoffs you are making – every bit of complexity added makes it harder for users to see value from your API. Security is essential for REST APIs because our organizations depend on them.

Some security issues can also be resolved by better Understanding how to use REST APIs & HTTP. In addition, an understanding of REST API’s constraints can go a long way in improving security and providing a better user experience.

Sharing is Caring

Brian is a software architect and technology leader living in Niagara Falls with 13+ years of development experience. He is passionate about automation, business process re-engineering, and building a better tomorrow.

Brian is a proud father of four: two boys, and two girls and has been happily married to Crystal for more than ten years. From time to time, Brian may post about his faith, his family, and definitely about technology.