Comments (10)
This question also came up recently when @inonshk and myself introduced the Top 10 at OWASP Global AppSec DC. This should definitely be addressed.
from api-security.
We need to decide if we are going to write a paragraph at the end of every Top-10 item, or create a summary of this at the end of the document.
It can also be in the form of a convenient table. Example:
Code Review | DAST | IAST | WAF | SAST | Alien Technology | |
---|---|---|---|---|---|---|
A1 | X | X | X | X | ||
A2 | X | X | X | X | X | |
A3 | X | X | X | X |
Thoughts?
from api-security.
Hi,
I think key point is that CISOs and other managers are not sure about differences in web app security detective/preventive controls and API ones. First thing is to highlight this, Whats applicable to both and whats not. From there, what are solutions to cover same topic on API side: dynamic code analysis is not convenient in app2app scenario. What about also insisting on 'continuous scanning/testing' by a red team or équivalent. What I noted in my company API strategy is a misunderstanding of api vs web and why things like WAF are not enough. Just a few evening thoughts @ appsec amsterdam. Happy tl discuss live tomorrow if people are present.
from api-security.
Hi all,
Personally I like the idea of both the table and the how to detect section. The table could possible help non technical individuals in finding out what team can assist them where as the how to detect section would help starting engineers like myself on finding the issues. I would be happy to assist in creating these sections.
from api-security.
I would be happy to assist in creating these sections.
You can review the initial draft: source, PDF.
Go through all top 10 weaknesses and check whether there's something missing in the "How to Detect" paragraphs.
Cheers,
Paulo A. Silva
from api-security.
Hi @tuxnam
Hi,
I think key point is that CISOs and other managers are not sure about differences in web app security detective/preventive controls and API ones. First thing is to highlight this, Whats applicable to both and whats not. From there, what are solutions to cover same topic on API side: dynamic code analysis is not convenient in app2app scenario. What about also insisting on 'continuous scanning/testing' by a red team or équivalent. What I noted in my company API strategy is a misunderstanding of api vs web and why things like WAF are not enough. Just a few evening thoughts @ appsec amsterdam. Happy tl discuss live tomorrow if people are present.
This could be a "What's Next for CISOs and Managers" section. What do you think?
Would you like to draft it? We would love to review/accept your PR.
Cheers,
Paulo A. Silva
from api-security.
from api-security.
Hi @tuxnam,
Thanks for your comments.
I would like to address them but I'll need your help.
Generic remark(s)
1.
A lot of scenarios/mitigations are assuming the organisation controls the API endpoint, the back-end application (if different) and the client.
Can you please point the Top 10 weaknesses where this happens?
The only assumption we should do regarding the organization is that it controls the API Server, nothing else. I agree that the "back-end application" can be other than the API Server and we should be careful about it.
2.
You can find/review it on feature/how-to-detect branch: we're waiting a few more comments before merging it into develop
for later release.
Broken Object Level Authorization
in How to prevent: Point 2: session object in a stateless world is a bit confusing.
You're right, this recommendation doesn't make sense for APIs.
It was removed (check develop branch) and it will be released soon.
Broken authentication
To give you some context, the first draft of this issue addressed mostly client authentication issues such as key management. Although this problem is very common, we realized that it's not an API issue but, instead, a Client issue.
On the other hand User Authentication problems are very common in APIs: the 4th most common weakness on collected data. Because of this, we re-factored this section to address User Authentication instead.
OAuth is not authentication, and certainly not API keys: true and written
all over the web, always good to remind readers: the key missing
information is always: what is API authentication then? Not sure relevant
for this paper but people get confused by reading this.
Any suggestions?
On how to prevent:
How do you implement MFA on APIs? It's (most of the time) application to
application flow. Same for captcha.
Based on given context, does the MFA recommendation make more sense?
Maybe we should discuss whether to rename this weakness "Broken User Authentication" (@inonshk, @ErezYalon).
I'd also add to prevent: ensure all API endpoints require authentication (I
have seen API calls where you could simply remove the bearer token, and get
a response)
What do you think about something like "Verify/test responses from endpoints requiring authentication, when no authentication token is provided."?
Sensitive data exposure
We don't have a "Sensitive Data Exposure" weakness but "Excessive Data Exposure" one ;)
I see your point, but we need to discuss whether it fits Excessive Data Exposure weakness (@inonshk, @ErezYalon).
Rate limiting
Docker is a good suggestion, an API gateway (which can help raise the bar
in most of the Top 10's) is another one.
Rate limit, if not granular enough, can also allow to DoS other users by
targeting the endpoint in a specific way.
Docker was referred as an easy way to accomplish resources limiting since it isn't as "easy" as rate limiting.
Rate Limiting can be implemented in several different ways/places (e.g., middleware, API Gateways, WAF, Firewall, ...): should we refer specifically API Gateways and nothing else or leave the recommendation as generic as possible?
Injection/Mass Assignment/ Rate Limiting
Can you please verify whether PR #23 matches your expectation?
Cheers,
Paulo A. Silva
from api-security.
from api-security.
After some messages we got, followed by internal discussions, it was decided not to include the How to Detect section in the inaugural version of the API Security Top 10.
Even just by mentioning detection technologies we felt that we might fall into unwanted "vendor wars" that would not be acceptable under OWASPs vendor neutrality, and might also divert the attention from the actual goal of this document: raising awareness to the rising importance of API Security.
This section may be considered again in future versions, or in the API Security cheatsheet.
from api-security.
Related Issues (20)
- 2023RC API8: Suggestion for the Prevention about detecting Non-human patterns
- Inconsistent Naming Improper Inventory Management HOT 1
- Additional configuration recommendations for API7:2023 Security Misconfiguration HOT 3
- Risk factors in all categories need rewrite HOT 4
- OWASP Production - need a license HOT 1
- OWASP Public Slack Channel HOT 1
- OWASP Production - all leaders are admins HOT 1
- OSSF passing - release notes for 2023 HOT 3
- OpenSSF passing - need a build script HOT 1
- Categorizations, rankings & data veracity. HOT 4
- Contradictory risk classification for "Unsafe Consumption of APIs" HOT 1
- Persian Translation for 2023 HOT 4
- Translation to Portuguese (pt-PT) for 2023 version HOT 2
- Translation to French (fr) for 2023 version HOT 1
- Translation to brasilian portuguese (pt-BR) HOT 3
- Missing link or resource in API2:2023
- Differentiation Between OWASP Top 10 and API Top 10? HOT 8
- Need a demo application having all top 10 api risks HOT 6
- API Lifecycle management HOT 1
- Odata with EF and .Net core Security risks with Front End queries through web components HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from api-security.