This week, the UK’s NCSC released detailed API security guidelines. Lorna Mitchell offers practical strategies for managing large OpenAPI files. Pieter Danhieux advocates for developer-focused security training in Australia. We also share best practices to secure your Postman collections and cover recent API vulnerability incidents at Zabbix and Shopware.
Article: UKs NCSC promotes secure API development
The UK’s National Cyber Security Centre (NCSC) has published a detailed set of guidelines for the secure development of HTTP-based APIs.
The guidance covers key areas including API design and threat modeling, documentation and asset management, and also secure development and testing practices.
A key recommendation is the use of standardized API specifications, notably OpenAPI, to fully document and describe APIs. OpenAPI enables clear and consistent documentation about the security controls required for an API, making it easier to test and verify whether those controls are implemented effectively.
The NCSC also emphasizes effective API version management to prevent the use of deprecated or insecure versions, helping to maintain a strong API security posture.
Article: Expert tips for mastering OpenAPI design
In “OpenAPI: How to Handle File Management”, Lorna Mitchell shares practical tips for managing OpenAPI files as APIs grow in size and complexity.
She highlights the value of a design-first approach and recommends using $ref syntax to reduce duplication and increase consistency. The article covers different ways to structure OpenAPI files, from the basics of shared components to more granular structures with one file per schema or operation. While each approach has trade-offs, the key takeaway is to find the right balance for your team’s workflow.
Increasingly, OpenAPI files play a central role in the API lifecycle. They power automated API testing, define runtime security requirements, and provide clear documentation for consumers.
That’s why having a solid process, and the right editor tool, to manage and navigate OpenAPI files is crucial for effective API governance.
Article: Championing Security-Aware Developers in Australia
In a recent CyberDaily.au op-ed, “Paving a pathway to better Australian cyber security preparedness,” Pieter Danhieux highlights the need to prioritize security awareness across all roles, especially developers. Since developers can eliminate vulnerabilities before code reaches production, investing in their security training offers an effective first line of defense.
This aligns with the principle of developer-first security in API development, which embeds security early in the process. By integrating tools and practices into developer workflows, organizations can build secure APIs from the ground up, making them more resilient to being exploited from common attacks such as the OWASP Top 10 list of API vulnerabilities.
Not incidentally, security expertise will remain crucial as code generation is offloaded to AI and the latest trends of vibe programming. LLMs are prone to vulnerabilities like prompt injection, so AI-generated code will still need to be reviewed by knowledgeable developers who can spot and correct vulnerabilities.
Article: Steps to prevent data leaks from Postman collections
A timely article on DZone emphasizes the importance of protecting sensitive information when using Postman for API development. It offers practical steps to prevent accidental exposure of credentials, API keys, and tokens. Some key recommendations include:
- Running Postman’s Secret Scanner to detect and alert users to exposed secrets within their Postman workspaces.
- Storing sensitive data in environment variables instead of hardcoding them into requests.
- Using short-lived tokens and rotating them regularly to minimize the risk of unauthorized access.
These steps are particularly important in light of the CloudSEK report covered in an earlier issue of this newsletter, which uncovered over 30,000 publicly accessible Postman workspaces leaking sensitive data such as API keys, credentials, and tokens.
Adopting the best practices outlined in the DZone article can help to mitigate these risks in your API development and testing environments.
Vulnerability: Zabbix API exposes OWASP security flaws
Zabbix, a widely used IT infrastructure monitoring platform, recently patched several API security vulnerabilities, including SQL injection, user enumeration, and excessive data exposure.
The SQL injection and data exposure issues follow common patterns frequently seen in API-related incidents. OWASP provides well-established guidance for preventing such vulnerabilities, including enforcing strict schema validation on both request and response payloads, and using prepared statements or parameterized queries to mitigate injection risks.
The user enumeration flaw exploited a timing discrepancy in the login API. When a non-existent username is submitted, the API responds immediately with an error. However, if the username exists, the API performs an additional password check before returning a failure, introducing a measurable delay. This timing difference allows attackers to determine which usernames are valid, enabling a user enumeration attack.
OWASP again offers guidelines on secure coding practices, with examples, to mitigate the risk from timing attacks. Recommendations include adding protections against brute-force attacks, which help to prevent user enumeration attacks at scale, as have been seen in recent cases of mass data scraping through APIs at Trello, Facebook and LinkedIn.
Vulnerability: Shopware API Vulnerable to SQL Injection
Another day, another API vulnerable to SQL injection!
Shopware provides a self-hosted open-source e-commerce platform written in PHP. One of the platform’s APIs was discovered to be vulnerable to SQL injection. A team of penetration testers reviewed the original vulnerability along with the patch subsequently provided by Shopware, and concluded that the patch, in the form of a security plugin, was incomplete and that the platform remained vulnerable to SQL injection.
The problem appears to be that the developer of the security plugin added security controls for the one property that was originally flagged as vulnerable, but didn’t check if other properties in the same API payload were also vulnerable to SQL injection. They were!
This is a good example of why secure by design is a better approach to the “firefighting” method of addressing vulnerabilities as they’re discovered. Rather than scrambling to patch individual instances of SQL injection vulnerabilities found in production, secure by design embeds security into the development process from the start, saving time and effort in the long run.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
