9 Questions For Top-Level API Security Auditing

6/19/2020 9 Questions for Top-Level API Security Auditing | Nordic APIs |
(https://nordicapis.com)
MENU
Blog
9 Questions for Top-Level API Security Auditing

(https://nordicapis.com/9-questions-for-top-level-api-
security-auditing/)
Kristopher Sandoval(https://nordicapis.com/author/sandovaleffect/)
July 3, 2018
(https://twitter.com/intent/tweet?
(https://www.linkedin.com/shareArticle?
(https://www.facebook.com/sharer.php? url=https%3A%2F%2Fnordicapis.com%2F9-
url=https%3A%2F%2Fnordicapis.com%2F9-
u=https%3A%2F%2Fnordicapis.com%2F9- questions-for-top-level-api-security-
questions-for-top-level-api-security-
questions-for-top-level-api-security- auditing%2F&text=9+Questions+for+Top-
auditing%2F&title=9+Questions+for+Top-
auditing%2F) Level+API+Security+Auditing)
Level+API+Security+Auditing)
https://nordicapis.com/9-questions-for-top-level-api-security-auditing/ 1/14
(https://19yw4b240vb03ws8qm25h366-wpengine.netdna-ssl.com/wp-content/uploads/9-Questions-for-Top-Level-API-
Security-Auditing.png)
One of the most important things any API developer can realize is the fact that, as a data handler, they have some of
the most important legal and moral requirements towards their data subjects of any technically oriented
organization.
The fact that consumers entrust developers with their data at all is predicated upon the idea that this data will be
secured, that the API itself will be bolstered against attacks, and that the API provider is doing everything within their
power to continually secure themselves against potential threats. With this in mind, the idea of auditing API security
is extremely important.
Today, we’re going to do exactly that. We’ll discuss 9 questions that every API provider should ask
themselves when it comes to security. While this is one potential guide for high-level API security auditing, we
hope it will be a jumping off point toward more specific questions along the API lifecycle.
The Benefits of an API Security Audit

Simply put, security is not a set and forget proposition. Threats are constantly evolving, and accordingly, so too
should your security. Gone are the days where massive spikes in technological development occur over the course
of months. The modern era sees breakthroughs in decryption and new methods of network penetration in a matter
of weeks (or days) after a new software release.
Of course, there are strong systems to implement which can negate much of these threats. Following a few basic
“best practices” for security (https://nordicapis.com/why-api-security-is-more-important-than-ever/) can negate a
bulk of the vulnerabilities, and as such, these best practices should be seen as a first line of defense.
Auditing can help expose wasteful endpoints, duplicate functions, consistently failing calls, and more, which if
reduced makes for a more maintained, and safer codebase. This also has the added effect of producing clearer
documentation, and taken to its logical conclusion, can make version management and iteration that much easier
and effective.
In other words, a security audit is not just a good idea in terms of securing your API – it’s a good idea for securing
the health of your API program, too.
9 Questions to Audit API Security

One way to audit an API is to separate our questions into three general categories according to the type of
consumer who will interact with the system. We can broadly separate these consumers into core functions,
generating Business Questions, Technology Questions, and User Relations Questions.
Business Questions
When we discuss business considerations, what we’re really looking at is the fundamental way in which the core
business competencies drive the API design and function. In other words, we’re looking at how the API supports the
business itself, and thereby identifying the various security concerns fundamental to the business functionality. This
includes how information is collected, how that data is retained, and various other aspects concerning partners and
internal policies.
1 – What Data Do We Collect – And Why?

Identifying why the business collects the data that it does is a huge first step towards ensuring security compliance.
GDPR (https://nordicapis.com/act-now-before-the-gdpr-deadline/) and other related legislation has brought data
privacy (https://nordicapis.com/privacy-laws-and-international-data-exchange-comparing-eu-and-us-standards/) to
the forefront in the consumer mind, but these issues have long been coming. The simple fact is that businesses, and
thereby their APIs, can very easily over-collect data. It might seem an easy way of going about things, but it may
create much bigger issues than it delivers in terms of value.
The biggest impact here is the fact that with greater amounts of collected data,
the data pipeline loses efficacy, and can potentially betray user privacy
expectations. This, together, makes the API a larger target, and thereby
decreases the overall security. An API should do much while exposing little – in
other words, it should provide excellent functionality without exposing exactly
how powerful it is.
If your API exposes massive amounts of data, from a pure cost/benefit analysis,
you are going to be a target. Furthermore, if you are breached, especially if
you function in any capacity with EU data or are under EU data protection laws
(https://nordicapis.com/complying-with-tough-new-eu-rules-on-data-
(https://19yw4b240vb03ws8qm25h3 protection/), your punitive possibilities are extreme.
66-wpengine.netdna-ssl.com/wp-
Look at your API, and reduce data collection to only that which is necessary.
content/uploads/Data-privacy-
Obtain explicit user consent for that collection – an “opt-out” option is no
APIs-GDPR-EU-regulation.png)
longer effective and, in many cases, does not guarantee GDPR compliance.
Understand new EU data protection laws
(https://nordicapis.com/complying-with- Obfuscate data (https://nordicapis.com/securing-your-datastream-with-p2p-
tough-new-eu-rules-on-data-protection/) encryption/) where appropriate, especially on endpoints. Most of all, minimize
your attack surface as drastically as possible while still allowing the basic
business functionalities required.
2 – Do We Have Internal Security Policies?

The unfortunate reality of data exposure is that most threats are not from external sources, but from internal threats,
poor security policies, inadequate training, and simple malfeasance. Even if the threat is not cognizant or purposeful,
simple human error can be much more damaging than any external attack due to the nature of internal access to
resources.
Thankfully, this area of threat can be mitigated perhaps more effectively than any other area in this auditing process.
Internal security policies are stated by internal members, and as such, can be tailored to your specific
organizations, its eccentricities, and its general weaknesses.
Hardening processes against social engineering, for example, can be relatively simple if systems are locked out from
access until the client provides two-factor identification, thereby removing the inherent insecurity of secret
questions.
IP theft can be prevented by separating systems and ensuring that clients accessing content via an API on a secure
server (https://nordicapis.com/the-benefits-of-a-serverless-api-backend/) and have their traffic routed independently
of other, less secure traffic sources.
Something as simple as ensuring proper distribution of responsibilities and powers amongst your employees can
go a long way towards ensuring security of this type and mitigating most common threats.
On creating internal policies: Fostering an Internal Culture of Security (https://nordicapis.com/fostering-an-internal-

culture-of-security/)
3 – Do We Trust Our Partners?

Insider threats are a serious concern, but the term itself is somewhat misleading. When we talk about insiders, we’re
not just talking about individual workers and those with code-level access – what we’re really talking about is the
threat from people with elevated, internal access of any kind. Unfortunately, that includes partners that have
elevated access for business-to-business (https://nordicapis.com/apis-are-evolving-the-b2b-landscape-2/) functions.
When you share data from your API with other third parties (https://nordicapis.com/first-or-third-party-apis/), you
are relying not just on them securing the data they’ve gotten from you, but on their own security being stringent
enough to secure their own data and their own API. Due to the nature of a business-to-business application, these
types of integrations tend to form symbiotic chains between the API partners, meaning what affects one partner will
likely affect the other.
In other words, if a partner’s system is compromised, there is the serious and real threat that endpoints that aren’t
meant to be exposed would in turn be exposed, thereby transferring much of the impact from an external point of
failure onto your internal systems.
Accordingly, any business security review must take into account an audit on external partners, their various
policies, and the systems into which they integrate your data stream. If you don’t have an SLA, or Service Level
Agreement, with that partner, or they aren’t 100% trusted and verified, they are not a partner you need to be
providing heightened access to.
Partner API Security Case Study: Cambridge Analytica & Facebook (https://nordicapis.com/learning-from-the-
cambridge-analytica-incident/)
Technology Questions
Technology concerns go beyond these business questions, and instead look at the technological implementations
of the core business competencies and their related functions. This is often the focus of most security audits and
implementations, and while this is an extremely important aspect of this auditing process, it is only part of the bigger
picture.
4 – Is Our Data Encrypted During Transit? What About Data at Rest?

Encryption (https://nordicapis.com/securing-your-datastream-with-p2p-encryption/) is a huge part of API security,
both in terms of data in transit and data in rest. Although encryption evolves randomly, major faults with older
methods are often discovered, so sticking with a single solution in impetuity is not a tenable approach.
Unfortunately, this seems lost on some data providers, as many of the most recent security issues have had lax data
security at its core.
Addressing your encryption methods and ensuring that they are adequate and secure is extremely important. While
at rest encryption is obviously important, it’s also just as important to ensure encryption in transit. The amount of
data pushed over HTTP is insane when one considers that HTTPS is much more secure and very easy to set up. It’s
not a perfect solution, sure, but it’s a better solution than sending over the clear, and when paired with other
advanced encryption, makes for a secure pipeline for data transit.
5 – Are We Overexposing? Are We Tipping Our Hand?

A big technical exposure can be found in the simple practice of exposing too much to too many in the API proper.
Simple things like not adequately rate limiting (https://nordicapis.com/stemming-the-flood-how-to-rate-limit-an-api/)
endpoints, exposing too much information in queries, or even documenting internal endpoints in external
documentation can tip your hand and expose much more about the API than was ever expected or desired.
As an example of this type of overexposure, we can look at something like

GraphQL. Since GraphQL allows for users to state what data they want and in
what general format, it’s conceivable that, without rate limiting, a nefarious
external user could use multiple API calls in different formats from different
endpoints to effectively map the entirety of the internal API routing, thereby
exposing the structure of the API itself and beginning to expose the
vulnerabilities that could be attacked.
In essence, this is akin to port scanning, and as any decent network

administrator can tell you, limiting access and locking down systems is a very
powerful, proactive method for securing your API.
(https://19yw4b240vb03ws8qm25h3
6 – Do We Have Any Gaps or Vulnerabilities? 66-wpengine.netdna-ssl.com/wp-
content/uploads/GraphQL-security-
While this might seem so simple as to not justify its inclusion, scanning for
implications.png)
gaps and vulnerabilities is a very important step in auditing – unfortunately, it’s
For more read: Security Points to
often seen as the only step, and as such, is better considered as part of a Consider Before Implementing GraphQL
process rather than as a single solution. Look at your codebase both at rest and (https://nordicapis.com/security-points-
to-consider-before-implementing-
in action, and look specifically for gaps and vulnerabilities arising from common
graphql/)
interaction.
These are often missed or ignored, especially when the vulnerabilities seem
small. The reality is a single small gap can cascade across multiple endpoints and products, resulting in a much less
secure system, and a propagation of weakness across the entirety of the system.
A big vulnerability, often associated with online databases, is using default settings and setup values. While it might
seem easy to just click a button and set up a default server, in some cases, this can leave data unencrypted, easily
grabbed, and sent over the clear. In fact, many of the most high profile data breaches (https://nordicapis.com/high-
grade-api-security-for-banks/) of the last ten years have occurred simply because the databases in question or the
services that secured them had little to no encryption and utilized default securing credentials.
User Relations Questions

To finish this picture, we also need to look at user relations. While we’re technically looking less at the API internal
security policy, and instead focusing on the security actions of those who utilize the API itself, the implications of
their use would suggest that any security failures aren’t necessarily because of their actions alone, but instead due to
the API even allowing those actions to occur in the first place. Accordingly, identifying the facilitating security holes
that allow users to break the system will go a long way towards rectifying any potential issues in the future.
7 – Are We Vetting Our Customers?

Most customers mean well. The customer just wants to use your API, often for their legitimate, well-informed, and
legal business purposes. Unfortunately, you can’t just trust all users because “most” do the right thing – especially
when some of your users want to use the API for massive amounts of data processing.
As such, vetting your customer base is a massively important issue for any
secure API. Make sure that customers are using their data access for the
proper reasons, and most importantly, establish a way to track baseline usage
and ensure that any deviations are properly addressed and managed.
An example of this type of threat would be the massive data misuse from
Cambridge Analytica (https://nordicapis.com/learning-from-the-cambridge-
analytica-incident/). The organization data-mined information from an app that
was published on Facebook for “academic purposes,” and used that data for a
multitude of different uses – all in violation of the terms of services from
Facebook itself.
(https://19yw4b240vb03ws8qm25h3
Another great method of dealing with these concerns is to grant new
customers rate-limited starter accounts until they’ve shown that their purposes
content/uploads/Terms-of-service-
are legitimate and their usage allowed. Another method is to tie into other
platform-policy.png)
federated networks with trusted userbases, allowing trust to be established by
A human-readable developer policy
(https://nordicapis.com/a-humans-guide- trusting their history on other networks.
to-drafting-api-platform-policy/) is the
first step toward enforcing API terms of Regardless of how you ensure your customer is trusted, this is of paramount
service. important to a secure API. Most attacks are going to originate from the inside,
not from random outsiders.
8 – Do We Have a Secure Front End?

Depending on the method by which a user accesses the API and its services, insecurity can arise not from the API,
but the frontend that ties into it. A web front utilizing Flash or Silverlight could, if those plugins utilize older builds,
expose vulnerabilities for script injection or other types of malicious code usage. Even something like an advertiser
widget displaying an advertisement on a login page could, in theory, be used to capture data about the browser and
user agent string, and in some malicious cases (https://nordicapis.com/world-war-api-cyberattacks-on-the-
international-scale/), may be able to use scripting to capture credentials using session captures.
Consider how the frontend operates. Does the API secure keys (https://nordicapis.com/why-cant-i-just-send-jwts-
without-oauth/) properly in transit? Is the key used for total authentication, or just as part of the process? Ideally, a
key should start the process of identification (https://nordicapis.com/scim-building-the-identity-layer-for-the-
internet/), but not solely prove ownership, thereby limiting damage. Are user rights escalation limited, or is there an
automatic system given their subscription level? These systems can be broken and users can sometimes maliciously
escalate their own privileges.
All of this is often overlooked, but it bears discussion – a frontend is just like your front door, and as important as we
consider locking our front door when leaving the house, so to should we treat our frontends with ample security!
9 – Is Your User Support Effective?

The way in which an API supports their users can have a dramatic effect on security. Often, security can be broken
down unintentionally, through users utilizing a system in ways the designers never planned for. Ample detection of
this, as well as documentation as to how a system should be properly utilized, can go a long way to mitigating
these user issues before they even pop up.
Additionally, consumer support systems can be leveraged as a method of reporting and identifying these issues
before they become larger than they already are. Simple reporting emails, a live support chat, or even a bug hunting
reward program can go a long way to ensuring users are reporting issues when they’re discovered, thereby having
an overall strengthening effect on your API.
Being proactive in this realm is hugely important. After all, if your users can find and exploit these issues, sometimes
even accidentally, then you can be sure that attackers can as well – the only difference being that attackers won’t be
kind enough to notify you as to the exposure, alerting you there’s a problem at all.
Conclusion
Security is an extremely serious and important part of any API, and as such, it
should be given the importance and weight that it deserves. These 9 basic
questions can do a lot of audit security, and frankly, they’re not that difficult to
address – adopting them as a frame of mind not only results in a greater
amount of security immediately, but has a compounding effect when used as a
structure for secure development.
Considering the possible fines, not to mention the loss of trust and commerce
that can come from being exposed or having an API used for nefarious
purposes, the benefits of adopting these questions and thinking hard about
security moving forward are immediate and compounding over time, delivering
(https://19yw4b240vb03ws8qm25h3 a safer, stronger, and more reliable API ecosystem.
content/uploads/api-security-
audit.png)
Head to our API Security Insights page
(https://nordicapis.com/api-
insights/security/) for more on securing
APIs!
 API audit (https://nordicapis.com/tag/api-audit/), API auditing Be the first to comment

(https://nordicapis.com/tag/api-auditing/), API security (https://nordicapis.com/tag/api- (https://nordicapis.com/9-questions-for-
security/), assessment (https://nordicapis.com/tag/assessment/), audit top-level-api-security-
(https://nordicapis.com/tag/audit/), auditing (https://nordicapis.com/tag/auditing/), business auditing/#disqus_thread)
(https://nordicapis.com/tag/business/), cybercrime (https://nordicapis.com/tag/cybercrime/),
developer feedback (https://nordicapis.com/tag/developer-feedback/), exploit
(https://nordicapis.com/tag/exploit/), internal audit (https://nordicapis.com/tag/internal-audit/),
IT security (https://nordicapis.com/tag/it-security/), secure (https://nordicapis.com/tag/secure/),
Security (https://nordicapis.com/tag/security/), security policies
(https://nordicapis.com/tag/security-policies/), support (https://nordicapis.com/tag/support/),
technology (https://nordicapis.com/tag/technology/), vulnerabilities
(https://nordicapis.com/tag/vulnerabilities/)
(https://nordicapis.c
om/author/sandova
Latest Posts
Calculating the Total Cost of Running an API Product

Tyler Charboneau June 18, 2020
(https://nordicapis.com/calculating-the-total-cost-of-running-an-api-product/)
New eBook Released: API Strategy for Open Banking

Bill Doerrfeld June 17, 2020
(https://nordicapis.com/new-ebook-released-apis-in-open-banking/)
The Role of APIs in DevOps
Eddie Segal June 16, 2020

(https://nordicapis.com/the-role-of-apis-in-devops/)
(https://nordicapis.com/events/livecast-maturing-platform-security/)
(https://nordicapis.com/events/platform-summit-2020/)
(https://docs.google.com/a/twobotechnologies.com/forms/d/12Ng9A_QKUjmAHDgv8Pxb4uLIkECGJawV3vwAWJ4WxTs/viewform)
Smarter Tech Decisions Using APIs
High impact blog posts and eBooks on API business models, and tech advice
Connect with market leading platform creators at our events
Join a helpful community of API practitioners
API Insights Straight to Your Inbox!

Can't make it to the event? Signup to the Nordic APIs newsletter for quality content. High impact blog
posts on API business models and tech advice.
tim@apple.com
Subscribe
Join Our Thriving Community

Become a part of the world’s largest community of API practitioners and enthusiasts.
Share your insights on the blog, speak at an event or exhibit at our conferences and
create new business relationships with decision makers and top influencers responsible
for API solutions.
Write
(https://nordicapis.com/create-with-us/)
Speak
(https://nordicapis.com/call-speakers/)
Sponsor
(https://nordicapis.com/about/contact-us/)
Events
Platform Summit 2020 (https://nordicapis.com/events/platform-summit-2020/)
Blog
Blog (/blog)
Business Models (https://nordicapis.com/category/business-models/)
Marketing (https://nordicapis.com/category/marketing/)
Platforms (https://nordicapis.com/category/platforms/)
Security (https://nordicapis.com/category/security/)
Strategy (https://nordicapis.com/category/strategy/)
Design (https://nordicapis.com/category/design/)
Resources
E-books (/api-ebooks/)
About
About (https://nordicapis.com/about/)
Press (https://nordicapis.com/about/press/)
Terms and Conditions (https://nordicapis.com/tscs/)
Volunteer (https://nordicapis.com/student-volunteer/)
Social
leffect/)
Kristopher Sandoval
(https://nordicapis.com/author/sandovaleffect/)
Kristopher is a web developer and author who writes on security and business. He has been
writing articles for Nordic APIs since 2015.
(https://www.linkedin.com/in/kristophersandoval/)
 How To Design Frictionless... (https://nordicapis.com/how-to-design-frictionless-apis/)
The Reality of Disruptive Tech

 (https://nordicapis.com/the-reality-of-disruptive-tech/)
Comments Community 🔒 Privacy Policy 

1 Login
 Recommend t Tweet f Share Sort by Best
Start the discussion…
LOG IN WITH
OR SIGN UP WITH DISQUS ?
Name
Be the first to comment.
✉ Subscribe d Add Disqus to your siteAdd DisqusAdd

⚠ D N t S ll M D t
s://www.linkedin.com/company/nordic-
(https://www.facebook.com/NordicAPIs) (https://www.youtube.com/user/nordicapis)
apis)
© 2013-2020 Nordic APIs AB | Supported by (https://curity.io) | Website policies (/policies/)

9 Questions For Top-Level API Security Auditing - Nordic APIs

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

9 Questions For Top-Level API Security Auditing - Nordic APIs

Hochgeladen von

Copyright:

Verfügbare Formate

6/19/2020 9 Questions for Top-Level API Security Auditing | Nordic APIs |

The Benefits of an API Security Audit

9 Questions to Audit API Security

1 – What Data Do We Collect – And Why?

2 – Do We Have Internal Security Policies?

On creating internal policies: Fostering an Internal Culture of Security (https://nordicapis.com/fostering-an-internal-

3 – Do We Trust Our Partners?

4 – Is Our Data Encrypted During Transit? What About Data at Rest?

5 – Are We Overexposing? Are We Tipping Our Hand?

As an example of this type of overexposure, we can look at something like

In essence, this is akin to port scanning, and as any decent network

User Relations Questions

7 – Are We Vetting Our Customers?

8 – Do We Have a Secure Front End?

9 – Is Your User Support Effective?

 API audit (https://nordicapis.com/tag/api-audit/), API auditing Be the ﬁrst to comment

Calculating the Total Cost of Running an API Product

New eBook Released: API Strategy for Open Banking

The Role of APIs in DevOps

Eddie Segal June 16, 2020

Smarter Tech Decisions Using APIs

Connect with market leading platform creators at our events

Join a helpful community of API practitioners

API Insights Straight to Your Inbox!

Join Our Thriving Community

Business Models (https://nordicapis.com/category/business-models/)

Terms and Conditions (https://nordicapis.com/tscs/)

 How To Design Frictionless... (https://nordicapis.com/how-to-design-frictionless-apis/)

The Reality of Disruptive Tech

Comments Community 🔒 Privacy Policy 

 Recommend t Tweet f Share Sort by Best

Start the discussion…

Be the first to comment.

✉ Subscribe d Add Disqus to your siteAdd DisqusAdd

© 2013-2020 Nordic APIs AB | Supported by (https://curity.io) | Website policies (/policies/)

Das könnte Ihnen auch gefallen