This week, we dive into API governance and API best practices, analyze a recently reported IDOR vulnerability at the Indian Post Office, and examine an SQL injection bug in the API of a popular Fintech platform. Finally, we review an API authorization vulnerability in Gitlab’s password reset mechanism.
Article: How Netflix and HSBC implement API Governance
A recent article on The New Stack argues that API teams should establish a formal governance pattern early, before an informal one takes root.
API governance provides a structured framework of policies and processes to guide API design, development, security, and maintenance. However, different organizations take different approaches, often influenced by their culture and operational needs.
The article reviews three key API governance patterns, analyzing their pros and cons through real world case studies of companies like Netflix, Paypal, HSBC and the Financial Times.
Some key takeaways:
- Netflix’s Central Design Authority (CDA) relied on manual API reviews by a dedicated team. While this ensured strong oversight, it quickly became a bottleneck as API development scaled. Automating design checks could have helped ease this burden.
- HSBC’s federated model of API governance introduced inconsistencies due to the varying levels of experience of API champions across the federated team. Here, increased automation helped to bring more consistency and improve governance.
For a deeper dive into API governance patterns and their real-world impact, this article is well worth a read!
Vulnerability: Lessons from India Post Office API Leaks
A security researcher recently uncovered an API vulnerability in the India Post Office website that exposed unauthorized access to sensitive Know Your Customer (KYC) information. The vulnerability highlights common pitfalls in API security practices, particularly around authentication and authorization.
One key takeaway from this case is how authorization was inconsistently applied. While the India Post website required users to log in to access their accounts, the underlying API calls to the backend did not require any credentials.
This suggests the API developers relied on the website for authentication, potentially assuming that all API requests would originate from the trusted website and therefore additional authorization checks directly at the API level were unnecessary.
Compounding the issue, the API was also found to be vulnerable to Insecure Direct Object Reference (IDOR). The API used a document ID parameter to retrieve KYC information:
GET /api/kyc/document?document_id=125678
If a malicious actor modified the document_id value to another customer’s document ID, the API would return the corresponding KYC information without verifying whether the requester was authorized to access that document. This lack of proper authorization controls made sensitive customer data easily accessible.
This case serves as a critical reminder for teams to enforce authentication and resource based authorization at the API, and never rely on client side security.
Vulnerability: SQLi bug in Financial Services Platform API
Fineract is a popular open source platform for Financial Services, providing an Open API based core banking solution. A recent report revealed that some of the platform’s REST APIs were vulnerable to SQL injection exploits. Fineract developers addressed the vulnerability by introducing a SQL Validator component, which, according to the vulnerability report: “allows us to validate and protect against nearly all potential SQL injection attacks“
SQL injection remains a common API security vulnerability, despite the fact that effective preventative measures are well-documented and widely promoted. OWASP highlights that successful SQL injection attacks occur when two conditions are met:
- An unintended data enters a program from an untrusted source.
- The data is used to dynamically construct a SQL query
A defense-in-depth approach to API security would ensure that neither condition is met. API teams should follow secure coding practices to:
- Validate input and constrain API query parameters to only accept expected and safe values, rejecting all other input by default.
- Use recommended secure mechanisms like prepared statements or stored procedures to remove SQL injection risks.
By consistently adopting security best practices, API teams can mitigate their exposure to SQL injection as well as other injection-based attacks.
Article: Best Practices in API Development
An article by NordicAPIs outlines key best practices for API development, emphasizing security, efficiency and building APIs that are easy to consume. Some of the recommendations include:
- adopting consistent naming conventions
- using HTTP methods appropriately
- adopting the Principle of Least Privileges
- planning for the full API lifecycle
In particular, the Principle of Least Privilege plays a crucial role in API security. By ensuring that users, applications, and services only have the minimum permissions necessary, organizations can significantly reduce their exposure to Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA) – two of the most exploited API vulnerabilities.
This article is a great refresher on API security fundamentals!
Vulnerability: Authorization Bug in Gitlab Password Rest API
I recently came across an interesting API security flaw on HackerOne. The original report dates back to 2023, but the vulnerability was only disclosed this week.
The issue involved Gitlab’s password reset function. A user could intercept the underlying API request and modify the payload to add a second email address. This appears to be a feature rather than a bug, since Gitlab allows users to specify a secondary email address to receive password reset notifications.
However, the feature contained a fundamental flaw. The relevant Gitlab release notes provide more details about the vulnerability.
The API failed to verify whether the second email address was registered and authorized for the target account. This error allowed an attacker to request a password reset for another user’s account, while adding their own email address as a recipient for a password reset link.
This case highlights multiple ways APIs can be exploited, through business logic abuse as well as insufficient authorization controls at the object or resource level.
Security testing can help to identify edge cases like these, where features could be exploited outside their intended use.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
