OWASP API Risks Updated - BOLA

As AI use and sophistication grow, BOLA attacks have risen rapidly.  Broken Object Level Authorisation (BOLA) is when an authenticated user can switch parameters like the URL in an API request and access other users' data. For example, GET https://api.example.com?client=32 returns the authenticated user's information, such as your age or other PII.

The authenticated user changes the client to "33"; I now get someone else's records, as the API only checks that I am an authenticated user, not that I am authorised to check another client.

Action	URL	Result
GET	https://api.example.com?client=32	The user sends valid authentication for their own client.  The result returns their data.  Correct.
GET	https://api.example.com?client=33	The user sends valid authentication for their own client data but requests another client's info.  The result returns the other client's private data.  Incorrect behaviour.  Major security issue.

Tools like Wiz and StackHawk will pick up BOLA API weaknesses.

Using StackHawk for DAST and API Security Testing on Azure

I recently started using StackHawk, and I am impressed with the tooling.  Its DAST and API security testing are outstanding, and it integrates beautifully with VS Code.

Application security requires more than simple source code scanning. While SAST, SCA, and secrets scanning are great in CI pipelines, key vulnerabilities remain hidden until an application is running. This is where Dynamic Application Security Testing (DAST) becomes essential.

In my development environment, Claude and GitHub Copilot are building my code and do so much of the Static Application Security Testing (SAST) 7I don't feel compelled to use them in the IDE.  Claude does a great job; it can do SAST and implement security best practices extremely well.

Software Composition Analysis (SCA) focuses on the third-party and open-source components our code relies on.  Claude once again does a great job of identifying vulnerabilities and upgrading to the latest versions.

Security secrets: Claude once again does a great job, especially with remote repo integrations such as GitHub, ADO, and GitLab.

Conclusion:

For enterprises building Azure-hosted web applications and APIs, StackHawk offers a developer-focused DAST approach that integrates directly into modern DevSecOps workflows. Unlike traditional DAST tools, which security teams often operate, StackHawk is designed to work with developers, providing rapid feedback during testing and deployment.  This "shift left" saves time and money. There are various DAST options, but StackHawk has become my favourite.  With the rise of AI coding, developer-level DAST is more important than ever.

BURP has been the standard for pen testing for many years.   Three DAST tools focus on different things: Burp Scanner, OWASP ZAP, and StackHawk.
Wiz API is a great test tool for API Security: runtime security, covering much of the same area as StackHawk for API security, but its key differentiator is runtime threat detection.

OWASP top 10 - 2021

 Always verify your system's have reviewed the OWASP top 10 vulnerabilities 2021: 

1. Broken Access Control (ensure users only see what they should have access too).  Permission need to be correctly specified and enforced.  i.e. don't allow customers to have Admin account privileges or access to another customers details.  Security needs to allow enough right/privileges so people and clients can do what they need to but must not over allow privileges.  Prevention techniques must include least privilege (no access by default and give the minimum needed permissions), audit access and changes (think tomb tables/temporal changes) but can also include access auditing and logging access control changes.  Lastly, QA must verify permissions work as expected, so often it is just assume it works as the QA thinks and not to actual policy/specification), 
2. Cryptographic failure (data in transit and at rest must be securely encrypted, more sensitive data must be more encrypted/scrambled.  By default everything should be encrypted but add extra encryption/controls to sensitive information like passwords.  For payment processing use a specialist provide like Stripe.  Encryption can be symmetric or asymmetric.  Ensure you use algorithms that are considered weak such as Triple DES also known as 3DES rather use AES, or hashing Algorithms such as SHA1 and RIPEMD160 are weak, rather use a SHA2 algorithm.  Manage your keys properly such as Azure Key Vault and rotate the keys regularly.  Salt hash key data to have encryption and hashing on sensitive data), 
3. Injection (data input results in unintended processing) examples are SQL injections and Cross side scripting (XSS),
4. Insecure Design (new addition in 2021, don't include sensitive information in error messages, ensure architecture can scale, passwords stored in plain text or are not rotatable, deal with DDoS, if 1 part of an app brings the whole solution down),
5. Security misconfiguration (default setup that is not very secure e.g. default password is not changed on installed software, ensure security hardening happens.  I.e. short passwords, changing passwords, updating software,...)
6. Vulnerable outdated components (we use components in code, if they have security weaknesses it's likely you also have it Log4J was an example.  You need to know all you supply chain dependencies so you need to ensure they are not vulnerable.  SAST scanning tools help identify vulnerabilities.  Know your component dependencies!), 
7. Identification & authorisation failures (You are who you say you are, check claims, use OAuth, OIDC example is session hijacking or stealing someone else's identification, public pc, next user logs in as you previous user),
8. Software and Data integrity failures (insured CI/CD pipeline, closely linked to item 6. example, could automatically update a nugget package to the latest automatically which has a security flaw in it),
9. Security Logging and Monitoring failures (check logs to detect security issues, incidents will happen and can often see people scanning for vulnerabilities),
10. Server-side Request Forgery (SSRF) (servers ask for endpoint info, use only-allow in headers or only allow the specific IP of the partner, ensure only relevant info is returned).