Security considerations of consuming public API

On top of what others have mentioned, I would suggest to follow these guidelines:

Third Party Schema Validation If the third party has a published swagger / OpenAPI schema and they have defined the structure of the API well (e.g. using minLength, maxLength, type etc.), make sure you validate the incoming data based on their schema.

Your Own Schema Validation Assuming you are using a portion of the incoming dataset, only extract that data and validate that the input is aligned with your expectation (e.g. for weather in degrees, validate it's an integer)

Use a third party malware scanning / validation tool for binaries If you are getting binaries, you can leverage a lambda function to scan the file, from using open source scanning with ClamAV (something in the lines of this article) or use VirusTotal for validation (here is an example with slack integration + lambda + virustotal)

Here are a few tips:

  • Check if there have been any major security issues with the third party API you are using
  • Treat the data coming in from the API the same as you would treat any user input
  • Make sure the third party supports TLS

To expand on the above answers by @mhr and @Raimonds-Liepiņš:

Validate Data

Meticulously validate all data pulled from the public API. Any text or "unknown" data must be filtered through a Security Encoding Library.

For example consider weather data being pulled from a public API.

  • Temperature - An acceptable temperature could be a negative or positive number and at most three digits. If three digits, the first number will always be a 1. Be specific. Anything different should error out.
  • Forecast Summary Text - Basic text using A-Za-z0-9 and standard punctuation. Define max amount of text allowed and produce an error for anything exceeding that threshold. Alternatively, consider truncating the data and apply ... suffix denoting this action. This data must be filtered through a Security Encoding Library.

Respect Rate Limits

Ensure your client will not abuse the rate limits placed on the public API. While the public API will likely have it's own method of enforcement, its best to be a good citizen and remain under the threshold.


TLS provides lots of protections as noted below. Require the use of a secure protocol (e.g. TLS 1.2) and strong cipher. Anything less should error out.

You get all of the benefits of an encrypted connection!

  • Assurance knowing you're connected directly to the target website via certificate validation. This protects against: Man-in-the-middle attacks, DNS hijacking, BGP hijacking, Domain spoofing (Why is HTTP not secure?).
  • The target website is more secure since all content is loaded over HTTPS. Some examples include protecting against posting from http to https and mixed-content while securing logins and cookies.
  • Some ISPs have been known to monitor connections for ad serving purposes which encryption defeats.
  • You're protected should an adjacent system become compromised.

Source: Does HSTS provide security advantages on private networks?


Since your post didn't include specifics regarding the framework being used and data consumed, the above is a generalized guideline that expands on the answers already provided. For specifics, take a look at OWASP as well as their Cheat Sheet Series. The main page may require some searching to find what you're looking for but will be well worth it.