Securing HTTP-based APIs
Pages
Page 2 of 8
1. Secure development practices
The impact of your API being compromised could disrupt operations, damage your organisation’s reputation and may even lead to fines from regulatory bodies. It is important to establish the context before designing a system as this will ensure that any security controls are proportionate to the threats you are facing. For example, an API used for a public weather forecasting app and an API used to manage a manufacturing line will have a totally different threat and risk profiles, which will translate to a different set of security controls.
Threat model your design
Start by threat modelling your high level design so you can understand any potential threats early in the design process. The NCSC’s guidance on threat modelling and OSWAP top 10 API threats can help with this.
Use a well-documented API
Comprehensive API documentation can provide asset management for your API design. This can be used to determine:
- the endpoints that should be exposed as part of the app
- the endpoints that should not be exposed (for example development or administrative endpoints)
- legacy endpoints
Good documentation will help ensure the correct security controls are being applied to parts of the API design that need it. Try to use a commonly used API specification such as OpenAPI to document and describe your API. Using an API specification that a community understands allows the use of common tools to be able to visualise and understand your API design.
As part of this documentation, make sure you manage API versions effectively to ensure that deprecated or insecure versions are not inadvertently used, and that clients are always using the latest secure versions. Versioning also enables you to deprecate and eventually sunset insecure or outdated API versions, thereby encouraging users to migrate to newer, more secure versions.
Secure development and testing
The NCSC uses the term ‘secure by design’ to describe a development approach that encourages organisations to ‘bake' cyber security into all stages of the product life cycle, rather than adding it as an afterthought. No matter how well-protected an API is, there is still a need for a secure development environment and code delivery. Once in production, any API should be subjected to appropriate security testing including negative and fuzz testing (not just positive testing) that is applicable to the threat model.
Using standards
When building an application that is using HTTP-based APIs, try to use well known, appropriate standards. This reduces the likelihood of a security weakness in your design. Some examples could include:
- using JSON for data exchange
- using OpenAPI to describe an API design
- using standard cryptography such as TLS for data in transit
There are many other standards that could be considered for your API design, and you should prioritise using tried and tested methods over building your own.
Asset register and governance
Asset registers and effective governance can help organisations maintain visibility, control, and protection over their APIs. An asset register serves as a comprehensive inventory detailing all API endpoints, services, and associated resources within an organisation's infrastructure. This register not only helps to identify potential vulnerabilities, but also enables efficient monitoring and management of assets throughout their lifecycle.
Effective governance ensures that policies, procedures, and controls are in place to safeguard these assets, aligning with industry standards and regulatory requirements.