Our ever-increasing reliance on APIs to provide products and services is resulting in an explosion in the digital footprint of most organisations. As organisations become API providers, they are experiencing new challenges in both managing their API infrastructure and aligning their team structure to the needs of delivering APIs. One area where this is particularly pertinent is API security.
API security is an aspect of cybersecurity that has implications across the organisation. Traditional views of cybersecurity heap responsibility on technical teams, with activities like penetration testing being the preserve of the IT security team and the relevant security professionals. APIs bring a new slant to this thinking. As APIs are often now considered a product in their own right, the focus shifts from “it’s a technology problem” to “it’s an organisational problem”.
Issues with API security can have a different perspective in the minds of consumers. A security breach in a backend system, whilst still a huge problem, is not necessarily associated with a given company product. A well-publicised breach of an API that is intrinsically linked with the organisation’s flagship product can, on the other hand, severely reduce the reputation capital of that organisation.
Having a laser focus on API security is an organisational concern of paramount importance. There are several areas around which an effective API security strategy revolves.
Buy-in from leadership
The first area of note in how an organisational view of API security affects stakeholders is in leadership. As APIs force their way up the organisation in terms of their importance, stakeholders will need assurance that APIs are secure. Responsibility for API security rests with digital leaders, and it will be their head on the block should a given API be compromised.
However, it’s more than just digital leaders who are responsible. APIs are increasingly becoming a product concern, with product team management responsible for what was once a technology concern. The key here is that leadership **must** view API security as part of the product and therefore consider API security itself to be a profit, not a cost centre. This is a fundamental part of the APIs-as-products way of thinking.
Product thinking for API security
The APIs-as-products mindset is one of the paradigm shifts as more and more organisations become API providers. In this way of thinking, product teams specifically own APIs, with each API or group of APIs earning a revenue stream, holding a budget being marketed to target groups of customers.
APIs-as-products means that API security is a core part of product thinking. Product people must take API security seriously and ensure that when they bring a product to market – implemented as an API – they are 100% sure the API is as secure as it needs to be and that the level of security meets customers’ expectations. This is a double-edged sword: The product must be secure enough to assure customers that how they use the API is secure, but it must also be easy to onboard and implement to ensure they can get up and running as quickly as possible.
The product team is not, however, the only security stakeholder. As API thinking permeates an organisation, risk and compliance will also be keenly interested in what an API exposes and how customers consume it.
Collaboration with risk and compliance
Risk and compliance in large organisations that expose APIs are vitally crucial for the smooth running of a public API programme. This statement may seem odd, given these teams are not technical. Their requirements will, however, significantly influence how the organisation publishes APIs.
The perspective of the risk team is likely to be influenced by the classic considerations of new product development. What data does the API expose? If that data is compromised, what mitigations are in place to limit the damage? What financial penalties will be levied if there is a data breach? Such information is critical to delivering a robust business case for an API and will allow API security to be tailored accordingly. Risk will also look at terms of use and ways to ensure they are correct and appropriate for the services offered.
On the other hand, compliance will look at how a given product complies with salient regulations concerning data security. Does the API comply with those regulations? If it does not, is there a plan to mitigate against fines that might result from non-compliance? What financial burden does this place on the organisation? Product and technical teams must ensure that they build security compliance into their development approach, with the means to demonstrate compliance readily available.
Risk and compliance must not, however, impede product development in the course of their actions. They facilitate product development by ensuring the go-to-market position is secure and derisked. They are there to ensure that the security of an API encompasses both relevant risk vectors and compliance with salient regulations. Acting on these requirements falls mainly into the technology realm, with teams ensuring they have the appropriate architecture and practices to deal with risk and compliance requirements.
Security architecture
Ensuring the security of products exposed as APIs means having an appropriate security architecture. Exposing public APIs increases the internet-facing footprint of an organisation’s products and services. The synergy between risk and compliance ensures right-and-appropriate terms and conditions. However, this must be supported by implementing a security architecture that protects APIs from miscreants and attackers.
The fundamentals of a relevant security architecture are well-understood. They include implementing API management with a mature API gateway that supports the appropriate security protocols for public APIs. The architecture must also ensure compliance with requirements for regulations.
If a given regulation demands an end user must actively assert authorisation for resource access – as in the open banking world – the relevant architectural building blocks must be in place. This particular example begets the implementation of an identity and access management component that helps ensure that end users can assert authorisation securely and protocol-compliantly.
Coding practices
The final aspect of note is secure coding, which is essential for API security. The OWASP API security guidelines provide best practices here. However, these practices – and any other organisational standards for API security – must not be taken lightly or be considered part of a product timeline that can be descoped if go-to-market dates are threatened. They are intrinsic to ensuring the quality, consistency and maintainability of the APIs in the market.
Therefore, API security for organisations is not something that just “happens”. It is a top-to-bottom activity with many stakeholders and requirements. Assurance of API security involves every team in the delivery chain. Organisations that do not employ a holistic view such as this will suffer.
