Importance of Securing Your Application Programming Interface (API)
Published Sources: SingCERT
What is affected, what to do
An Application Programming Interface (API) facilitates service communications between two or more applications. APIs are vital in today's highly digitised world as they provide flexibility by simplifying software design, administration and use.
The available sources name no fixed version. Check the vendor guidance in the references below.
Not sure whether and how you are affected? Ask a question about this vulnerability
Metrics
—
Priority
No value is available for this vulnerability.
—
CVSS v3
No value is available for this vulnerability.
—
EPSS score
No value is available for this vulnerability.
Show all metrics
- Severity
- Not rated
Priority (0–325)
The priority score is a consolidated metric that condenses several individual signals into a single, action-guiding ranking: technical severity (CVSS), exploitation likelihood (EPSS), known-exploited status (KEV) and the context of the affected asset. The aim is to answer the only truly important question in vulnerability management: what first?
Read in glossary- 1.57 Methodology
Exploit maturity
An exploit is code or a technique that specifically uses a concrete vulnerability to force unintended behaviour — such as executing code or escalating privileges. It is the tool that turns a theoretical flaw into a practical attack.
Read in glossary- no public PoC known
KEV status
The KEV catalogue is a list maintained by the US authority CISA of vulnerabilities for which active exploitation in the wild has been confirmed. It answers not the question „how severe?“ but „is it already being attacked?“ — thereby sharply prioritising patching.
Read in glossary- —
- Published
Classification under NIS2 and CRA
Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.
NIS2
NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.
Read in glossary- Handle the vulnerability in regular vulnerability handling under Art. 21(2)(e) NIS2.
CRA
The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.
Read in glossary- From 11.12.2027, Annex I Part II CRA requires manufacturers of affected products with digital elements to handle vulnerabilities without delay and provide security updates.
ISO/IEC 27001
ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.
Read in glossary- Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.
Description
An Application Programming Interface (API) facilitates service communications between two or more applications. APIs are vital in today's highly digitised world as they provide flexibility by simplifying software design, administration and use. This exponential increase in the use of APIs widens the attack surface area. APIs are also the most commonly exposed component of a system. This advisory serves to inform users and administrators of APIs on how to better secure the APIs in their systems. Examples of Common Attacks on APIs In order to understand how to secure an API, it is important to know the different types of attacks that are employed against it. Some examples of common attacks on APIs are shown below: Injection attacks Poor implementation of an API such as the lack of input sanitisation could cause the API to process malicious SQL commands or code, possibly resulting in data breaches or system compromise. Man-in-the-Middle (MITM) attacks Interception of an API request or response between an end user and an API could allow an attacker to steal information such as credentials or modify the content of the request or response. Denial-of-service An attacker can overload an API's processing capabilities which leads to a denial-of-service condition. RBAC and ABAC exploits Poorly defined Role-based access control (RBAC) and attribute-based access control (ABAC) could be exploited by an attacker to escalate privileges and steal or modify data Credential Stuffing Leaked or stolen credentials obtained from past data breaches may be leveraged to ‘stuff’ into the login pages of online services. This method takes advantage of end users who use the same username and password combinations across different accounts. Best Practices for API Security Users and administrators may wish to consider several best practices for API security as illustrated (non-exhaustive) below to mitigate cybersecurity incidents involving APIs. Institute Diligent Documentation Each API used should have an accompanying document or manual that contains all technical requirements, including the functions, classes, return types, arguments and integration processes of the API. This repository should be regularly updated according to established change management policies to allow users and administrators to take stock of APIs which exist in their system and how best to secure and manage them. Encrypt all API Traffic APIs should also use and require Hypertext Transfer Protocol Secure (HTTPS) as it provides stronger guarantees that a client is communicating with the real API and receiving back authentic contents. All API traffic should also be encrypted using Transport Layer Security (TLS) encryption to prevent MITM attacks. Use a Strong Authentication and Authorisation Solution Since APIs provide an entry point to an organisation’s databases, it is critical that organisations strictly control access to them. API users and administrators should use proven authentication and authorisation mechanisms such as OAuth2.0 and OpenID Connect to control, where feasible. Implement Rate Limiting Implement rate limiting and limit payload sizes based on established rules/policies to defend against denial-of-service attacks or brute force attacks. Use a Web Application Firewall Web application firewalls protect web applications and APIs from attacks. It also enables the configuration of a web access control list (ACL) to allow, block or count web requests based on customisable web security rules and conditions defined by the user or administrator. Monitor and Log API Activities Threat detection tools could be used to detect any anomalous behaviour in API traffic and facilitate the implementation of appropriate mitigation measures. Log data could also be used to understand the root cause of any security incident and help in the implementation of any hardening measure. API Penetration Testing Engage credible cybersecurity vendors to perform periodic penetration testing to assess the security of the API design. The API tests usually involve attempting to exploit identified vulnerabilities and reporting them to system users and administrators. By assessing the risks and weaknesses in the design and implementation of the API, appropriate mitigation measures can be incorporated to ensure the security of the API. Practice the Principle of Least Privileges The principle of zero trust and least privileges should be consistently practiced, with each API given the minimum privileges and access necessary to perform its functions. Input Validation Use prepared statements, parameterised queries or stored procedures whenever possible to mitigate potential attacks like cross-site scripting and SQL injection. Minimise Data Exposure Any API response should only include the specific information requested or the success/failure of the request. All related passwords and keys used during development should also be removed before making the API publicly available. Review RBAC and ABAC Rules Regularly RBAC and ABAC rules should be reviewed whenever any updates are made to the application to ensure that no security regression is introduced with the update. Conduct Regular Security Audits Regular security audits should be conducted to ensure that appropriate measures are in place to prevent any potential abuse of deployed APIs. Reporting a Compromise If your organisation is a victim of any cybersecurity incident involving APIs or otherwise, you are encouraged to report the incident at https://go.gov.sg/singcert-incident-reporting-form . References: https://www.securitycompass.com/blog/10-proven-best-practices-for-secure-api-development/ https://www.techtarget.com/it-infrastructure/tip/13-API-security-best-practices-to-protect-your-business https://owasp.org/www-project-api-security/ https://blog.mia-platform.eu/en/api-security-best-practices-to-protect-your-digital-channels https://blog.axway.com/learning-center/digital-security/keys-oauth/api-security-best-practices https://www.f5.com/labs/learning-center/securing-apis-10-best-practices-for-keeping-your-data-and-infrastructure-safe
Source: CSA/SingCERT