9 ms·

OWASP Top 10 2021

360 points by chha 5y ago

laurent123456 5y ago
Should be the full title: "Introduction to OWASP Top 10 2021", because it's specifically about the new top 10 this year.
- chha 5y ago
  Fixed.
makach 5y ago
Wow! Great job! Readability is extremely important! By making it easier to see what the current major threats are will make us more focused and secure in the long run!
raesene9 5y ago
Some interesting changes in the Top 10 this time around and in general, I think they're good changes. It does suffer a little bit though from some of the entries being quite wide ranging and non-specific, which I think could leave people scratching their heads about exactly what's involved. I'm glad to see that monitoring and logging is still included as, in many years as a web app pentester, it was really common to see no application level detection and response to security attacks.
- emn13 5y ago
  Speaking of non-specific, what exactly is A04:2021-Insecure Design supposed to be? That category sounds almost circular in its reasoning: Your software isn't secure because... it's design is insecure? https://owasp.org/Top10/A04_2021-Insecure_Design/ https://owasp.org/Top10/A04_2021-Insecure_Design/ elaborates slightly, but this still strikes me as such a catch-all, it's not going to be easily actionable.
  - raesene9 5y ago
    yeah that's the kind of entry I'm thinking about. I'm hopeful that in the full version they'll explain more detail but it will need that explanation to make it meaningful.
  - capableweb 5y ago
    This is what the submission says about "Insecure Design" > A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures. Seems pretty clear it's about upfront security thinking, planning and education. Of course all of these items in the list are gonna be general as they are categories, not specific line items.
  - blincoln 5y ago
    I interpreted that one (perhaps too charitably) as being about business logic flaws, design decisions that are inherently dangerous, that sort of thing. i.e. most of the other things on the list are issues that were introduced unintentionally, and this one is about decisions made by designers and developers that were themselves the problem.
    - monbis 5y ago
      Yup this is what I read, and covers a lot of security reviews I have come across, where someone requests some functioanlity, such as password recovery, or some promotional code, and someone else discovers how it can be exploited. I'd say long overdue.
  - knightofmars 5y ago
    Some examples. 1. Providing a permission based check to prevent a user from accessing a specific UI page but then failing to secure the back-end API endpoint that supports the UI. A developer implementing a user story reads the following acceptance criteria, "User without permission X cannot see page Y." and proceeds to prevent the UI page Y from rendering if the user doesn't have permission X. They completely ignore securing the back-end API endpoint as that's not a requirement. Now you have a back-end API endpoint that isn't doing any permission checks and anyone can call it even if they don't have permission X. 2. Allowing different values to be used when checking authorization and subsequently persisting data. A user posts to a URL to add an item to an order. URL: POST /app-web/orders/144/items PAYLOAD: { "item_id":682, "order_id":555 } @POST("/orders/{orderId}/items") public void addItem(@PathParam("orderId") Integer orderId, OrderItem orderItem) { checkOwnsOrder(orderId); repo.create(orderItem); } The application logic is written to check that the user has access to the order identified in the URL (144). But the payload has a different order id (555). The application allows the item to be added to the order but in this case the order being altered is order number 555 and not the order that the user originally had the ability to add items to, 144.
plasma 5y ago
New to the list is Server-Side Request Forgery (SSRF), where you trick the remote server to fetch a sensitive URL on an attackers behalf (eg, internal service or cloud metadata URL from the context of an internal server), a language-agnostic defense is using something like Stripe's Smokescreen [1] which acts as a SOCKS proxy your app connects to when requesting URLs that should be quarantine'd, and it does the enforcement of access to internal/external IPs or not. [1] https://github.com/stripe/smokescreen https://github.com/stripe/smokescreen
- raesene9 5y ago
  SSRFs are great fun and used on pentests a lot. One of my favourites was where you could hit the cloud metadata service from an application and potentially get credentials back.
- Closi 5y ago
  Would the exploit of Google's thumbnail service count as this, where you could ask it to provide a thumbnail of someone else's private document?
  - weird-eye-issue 5y ago
    Yes
- freeqaz 5y ago
  We built something similar at both Uber and Snap. Thanks for sharing this link to an open source equivalent! I wish it had existed a few years ago when I had looked. Oh well!
  - csmpltn 5y ago
    > "We built something similar at both Uber and Snap. Thanks for sharing this link to an open source equivalent! I wish it had existed a few years ago when I had looked. Oh well!" Why not just use a firewall? The technology has been around since the 80s?
1cvmask 5y ago
Authentication and Broken Access Controls are two separate categories. I would have put authentication as a subset of Broken Access Controls. At saas pass we see authentication and mfa as a subset of identity and access management and the access controls.
dspillett 5y ago
I'm not sure server-side request forgery needs to be its own category where request forgery covers things from all sides. Server-side attacks are more common as systems get more complex and have many moving parts that need be able to trust each other (in microservice architectures for instance), but failing to account for forgery at all levels is more a security-in-depth failure (fitting in the new very vague “insecure design” category?). Unless I'm misunderstanding what is being meant here, which is far from impossible!
- billyhoffman 5y ago
  I mentally bucket Server-side request forgery separately from Client-side request forgery because of who it impacts. - With SSRF, I'm tricking your server-side system into requesting and returning to me something it shouldn't (local/intranet files, local/intranet network responses, the EC2 instance metadata endpoint). As a developer, SSRF can leak my app/infra/data/secrets to an outside attacker - With CSRF, I'm tricking a legit user into performing an authenticated action an existing application allows. Much closer to automated click-jacking.
cedricbonhomme 5y ago
Nice, thank you for this list! It is now possible to import these items in the MONARC security assessment software: https://objects.monarc.lu/schema/14 https://objects.monarc.lu/schema/14 ;-)
freeqaz 5y ago
For the "broken access controls", "cryptographic failures", and "bad design" categories, I've been working on an open source project to help mitigate those. It's still early and I haven't released it yet, but I have the docs[0] deployed now. If anybody feels like helping us test this early, I'd love some feedback. We're going to be pushing the code live in a week or so. (It's been a lot of building for a while now) I've been thinking about these problems for a while now (as a security engineer) and it's cool to see that my intuition is roughly in line with what OWASP is seeing these days. It's always hard to know if the problems you see people struggling with are representative of the industry as a whole, or if you're just in tunnel vision. Note: We're building this as a company so that we can actually afford to continue doing this full time. I'm still learning how to find the line between open source and a viable business model. Any thoughts would be appreciated[1]! 0: https://www.lunasec.io/docs/ https://www.lunasec.io/docs/ 1: email me at, free at lunasec dot io
- red0point 5y ago
  Can you tell me how the limitation of the creation of read grants in luna is done?
  - freeqaz 5y ago
    We have a few different strategies for this. You can read through the "levels" here[0]. (We need to expand on this doc still) Level 1: There are no grants. Level 2: Access requires a "shared secret" in order to authenticate to the Tokenizer. If you have the secret, get API access to the Tokenizer, and you have a copy of a token, then you can create a grant. In order to use the grant, you also need a valid session for the front-end, but if you have RCE on the back-end then you can get this pretty easily. Level 3: Creating grants also requires presenting a JWT that's signed by an upstream "Auth Provider" that also proxies traffic. This JWT is only able to create grants that are scoped to a specific session (which is identified using a "session id" inside of the JWT). You can still create a grant every token you have access to, but you need to get a valid session to do so. In this design, the proxy strips the cookies from the request and only forwards the JWT, which adds another step to the attack (you have to be able to login to on a browser). This requires that you put your "Root of Trust" into your authentication provider, so you would want to "split" out your authentication/session creation into another service. We have an example app + tutorial explaining this that we'll publish soon. Level 4: You write a separate function,called a "Secure Authorizer", that accepts a session JWT and a Token in order to "authorize" that a grant can be created for a given user. This function is deployed in a hardened container and is difficult to attack (a network restricted Lambda). By adding this layer, you now require that an attacker is able to generate sessions for any user that they want to leak data from. Or you require them to attack the "Secure Authorizer". It's a much more painful attack for an attacker to pull off once you've integrated all of these layers. Does that answer your question? I'll make sure go add this explanation into that levels page. Oh, and thanks for reading the docs! :) 0: https://www.lunasec.io/docs/pages/overview/security/levels/ https://www.lunasec.io/docs/pages/overview/security/levels/
ThePhysicist 5y ago
Interesting that "broken access controls" made it into the top spot. Not sure if this anecdotal but recently I've seen many "hacks" of apps built with external BaaS & auth providers that rely on some kind of token-based authentication, either via JWT or opaque tokens. What happens is that often the providers offer good support for role-based access control but developers just plain ignore it and e.g. include tokens with global read permissions into the app code, or do not properly restrict the permissions of individual tokens, making it possible to e.g. read the whole database with a normal user token. The researcher collective Zerforschung [1] e.g. has uncovered many such incidents. That might have to do with the fact that in my experience those BaaS frameworks and other low-code tools are mostly used by teams with a strong focus on product and UI/UX, which don't have deep security expertise or the right mindset. I think overall outsourcing of aspects like authentication can be beneficial, but only if teams adopt or retain a healthy security awareness as well. [1] https://twitter.com/zerforschung https://twitter.com/zerforschung
- thinkharderdev 5y ago
  I worked on an identity provider platform and this was always such a huge problem. Many application developers treat authentication as an all or nothing proposition: either a user is authenticated or they are not, but the reality is that authorization is truly hard part and often completely overlooked. This is especially true in Oauth2/OIDC schemes where JWT bearer tokens are issues. At that point you are delegating token validation and access control out to all clients. Even if you are using opaque tokens to prevent basic token verification issues, you still just end up doing the token validation for the client. They still are responsible for access controls on specific resources.
  - fendy3002 5y ago
    Out of topic, I use oidc provider (keycloak). I fetch the public key from oidc provider then verify the bearer token with it. Then use the permissions field to authorize users based on their permission. Does my approach correct / suffice?
    - 5y ago
kingkongjaffa 5y ago
I had to go to the github then to https://owasp.org/ https://owasp.org/ to figure our what the heck OWASP even stood for! For those stumbling onto this: The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software.
- bibinou 5y ago
  on desktop, I see About OWASP in the sidebar: https://owasp.org/Top10/A00-about-owasp/ https://owasp.org/Top10/A00-about-owasp/
  - kingkongjaffa 5y ago
    Ahh I see, I did not get that far down the page, I got to https://owasp.org/Top10/A00_2021_Introduction/ https://owasp.org/Top10/A00_2021_Introduction/ and couldn't figure out what OWASP was.
- putnambr 5y ago
  Every (software engineering) job I've had has had OWASP trainings, if not explicitly listed knowledge and integration of OWASP principles as a job responsibility for levels above entry. What sort of security principles do you follow?
querez 5y ago
The homepage does a very poor job of giving any context, so for those who (like me) who have no clue what they're looking at: This list represents a broad consensus about the most critical security risks to web applications. See https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-top-ten/ for more details (OWASP = "Open Web Application Security Project").
- chha 5y ago
  Just to give some more context; this is a list that has been updated every 2-4 years since around 2004 or so. A lot of orgs treat it as the minimum a developer needs to know in terms of security, so it's time well spent looking through it (IMO)
- jasonlotito 5y ago
  On the home page: https://owasp.org https://owasp.org "The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web." About the OWASP Top 10 "The OWASP Top 10 is a book/referential document outlining the 10 most critical security concerns for web application security. The report is put together by a team of security experts from all over the world and the data comes from a number of organisations and is then analysed." Seems pretty spot on to me. And OWASP should be very well known by anyone working in the web field.
ludovicianul 5y ago
I'm honestly happy I see "Insecure Design" into the list. With all the buzzwordy Agileness people often forget that (at least) high level design is important and brings a lot of value if done early on.
Yuioup 5y ago
Is there a hi-res version of the "2017 vs the 2021" image? I'd like to share it with my colleagues. [Edit] Same goes for the other images such as the Venn Diagram.
- another-dave 5y ago
  They're pretty big images if you open/download them directly — https://owasp.org/Top10/assets/image1.png https://owasp.org/Top10/assets/image1.png https://owasp.org/Top10/assets/image2.png https://owasp.org/Top10/assets/image2.png Not print quality (when you say hi-res, not sure) but definitely readable
gibbiv 5y ago
A few weeks ago I realized OWASP has a top 10 for API security as well. The first version was published in 2019. There are enough differences in API security versus application security to warrant a separate list. However, that project is very light in terms of Docs: https://owasp.org/www-project-api-security/ https://owasp.org/www-project-api-security/
DiffEq 5y ago
Notice the Venn Diagram at the bottom of the page. If you were going to put money in a security solution you would do your best work if you made sure your security related configurations were correct and remained in place. (Least privilege configuration and Change Control). It affects every other category except injection and known vulnerabilities. So then you would make sure you had good life cycle management and patch management to address the issues with software vulnerabilities and then make sure you use Prepared Statements (with Parameterized Queries) or properly constructed Stored Procedures. This is where your focus and money should go before you start doing anything else.
Ekaros 5y ago
Seems like this is still a draft and release will be later this month. Still specially design and CI/CD seem good points to include from security professional's perspective.
Macha 5y ago
I wonder which one the "REST endpoint just JSON serializes and spits out the whole database row" problem falls under now? I previously thought sensitive data exposure included this case.
tptacek 5y ago
The former category for XML External Entities (XXE) is now part of [Security Misconfiguration]. Insecure Deserialization from 2017 is now a part of [Software and Data Integrity Failures] [...] focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. These seem like nonsense statements. XXE's aren't misconfiguration (in any sense that a myriad of other vulnerabilities aren't "misconfigurations" of libraries), and deserialization bugs aren't software update bugs (I don't even know what CI/CD is doing in that description). The OWASP Top 10 is rapidly losing coherence. It's important not to take it too seriously. For all the pantomime about survey data, there's not much real rigor to it. It's mostly a motivational document, and a sort of synecdoche for "all of web app security". The best part of this is the end, where they say "we have no data to support having SSRF on the list, but 'industry people' tell us it's too important not to". Gotta side with the industry people on that one. But maybe you can cram it into "Insecure Design" next year and be rid of it!
- mwcampbell 5y ago
  > The OWASP Top 10 is rapidly losing coherence. Do you have any recommendations of better resources for web application developers needing to learn about security?
valgor 5y ago
It says "CWE" a lot, but does not say what a "CWE" is. Anyone know?
- swid 5y ago
  Common Weakness Enumeration - like a public bug report related to security, which is not managed by the developers of the software / hardware. https://cwe.mitre.org/ https://cwe.mitre.org/
benfrancom 5y ago
Another data point referenced in InfoSec circles is the "Verizon Data Breach Investigations Report" https://www.verizon.com/business/resources/reports/dbir/ https://www.verizon.com/business/resources/reports/dbir/

OWASP Top 10 2021

360 points by chha 5y ago

Should be the full title: "Introduction to OWASP Top 10 2021", because it's specifically about the new top 10 this year.

chha 5y ago
Fixed.

makach 5y ago

Wow! Great job! Readability is extremely important! By making it easier to see what the current major threats are will make us more focused and secure in the long run!

raesene9 5y ago

Some interesting changes in the Top 10 this time around and in general, I think they're good changes. It does suffer a little bit though from some of the entries being quite wide ranging and non-specific, which I think could leave people scratching their heads about exactly what's involved. I'm glad to see that monitoring and logging is still included as, in many years as a web app pentester, it was really common to see no application level detection and response to security attacks.

emn13 5y ago
Speaking of non-specific, what exactly is A04:2021-Insecure Design supposed to be? That category sounds almost circular in its reasoning: Your software isn't secure because... it's design is insecure? https://owasp.org/Top10/A04_2021-Insecure_Design/ https://owasp.org/Top10/A04_2021-Insecure_Design/ elaborates slightly, but this still strikes me as such a catch-all, it's not going to be easily actionable.
- raesene9 5y ago
  yeah that's the kind of entry I'm thinking about. I'm hopeful that in the full version they'll explain more detail but it will need that explanation to make it meaningful.
- capableweb 5y ago
  This is what the submission says about "Insecure Design" > A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures. Seems pretty clear it's about upfront security thinking, planning and education. Of course all of these items in the list are gonna be general as they are categories, not specific line items.
- blincoln 5y ago
  I interpreted that one (perhaps too charitably) as being about business logic flaws, design decisions that are inherently dangerous, that sort of thing. i.e. most of the other things on the list are issues that were introduced unintentionally, and this one is about decisions made by designers and developers that were themselves the problem.
  - monbis 5y ago
    Yup this is what I read, and covers a lot of security reviews I have come across, where someone requests some functioanlity, such as password recovery, or some promotional code, and someone else discovers how it can be exploited. I'd say long overdue.
- knightofmars 5y ago
  Some examples. 1. Providing a permission based check to prevent a user from accessing a specific UI page but then failing to secure the back-end API endpoint that supports the UI. A developer implementing a user story reads the following acceptance criteria, "User without permission X cannot see page Y." and proceeds to prevent the UI page Y from rendering if the user doesn't have permission X. They completely ignore securing the back-end API endpoint as that's not a requirement. Now you have a back-end API endpoint that isn't doing any permission checks and anyone can call it even if they don't have permission X. 2. Allowing different values to be used when checking authorization and subsequently persisting data. A user posts to a URL to add an item to an order. URL: POST /app-web/orders/144/items PAYLOAD: { "item_id":682, "order_id":555 } @POST("/orders/{orderId}/items") public void addItem(@PathParam("orderId") Integer orderId, OrderItem orderItem) { checkOwnsOrder(orderId); repo.create(orderItem); } The application logic is written to check that the user has access to the order identified in the URL (144). But the payload has a different order id (555). The application allows the item to be added to the order but in this case the order being altered is order number 555 and not the order that the user originally had the ability to add items to, 144.

plasma 5y ago

New to the list is Server-Side Request Forgery (SSRF), where you trick the remote server to fetch a sensitive URL on an attackers behalf (eg, internal service or cloud metadata URL from the context of an internal server), a language-agnostic defense is using something like Stripe's Smokescreen [1] which acts as a SOCKS proxy your app connects to when requesting URLs that should be quarantine'd, and it does the enforcement of access to internal/external IPs or not. [1] https://github.com/stripe/smokescreen https://github.com/stripe/smokescreen

raesene9 5y ago
SSRFs are great fun and used on pentests a lot. One of my favourites was where you could hit the cloud metadata service from an application and potentially get credentials back.
Closi 5y ago
Would the exploit of Google's thumbnail service count as this, where you could ask it to provide a thumbnail of someone else's private document?
- weird-eye-issue 5y ago
  Yes
freeqaz 5y ago
We built something similar at both Uber and Snap. Thanks for sharing this link to an open source equivalent! I wish it had existed a few years ago when I had looked. Oh well!
- csmpltn 5y ago
  > "We built something similar at both Uber and Snap. Thanks for sharing this link to an open source equivalent! I wish it had existed a few years ago when I had looked. Oh well!" Why not just use a firewall? The technology has been around since the 80s?

1cvmask 5y ago

Authentication and Broken Access Controls are two separate categories. I would have put authentication as a subset of Broken Access Controls. At saas pass we see authentication and mfa as a subset of identity and access management and the access controls.

dspillett 5y ago

I'm not sure server-side request forgery needs to be its own category where request forgery covers things from all sides. Server-side attacks are more common as systems get more complex and have many moving parts that need be able to trust each other (in microservice architectures for instance), but failing to account for forgery at all levels is more a security-in-depth failure (fitting in the new very vague “insecure design” category?). Unless I'm misunderstanding what is being meant here, which is far from impossible!

billyhoffman 5y ago
I mentally bucket Server-side request forgery separately from Client-side request forgery because of who it impacts. - With SSRF, I'm tricking your server-side system into requesting and returning to me something it shouldn't (local/intranet files, local/intranet network responses, the EC2 instance metadata endpoint). As a developer, SSRF can leak my app/infra/data/secrets to an outside attacker - With CSRF, I'm tricking a legit user into performing an authenticated action an existing application allows. Much closer to automated click-jacking.

cedricbonhomme 5y ago

Nice, thank you for this list! It is now possible to import these items in the MONARC security assessment software: https://objects.monarc.lu/schema/14 https://objects.monarc.lu/schema/14 ;-)

freeqaz 5y ago

For the "broken access controls", "cryptographic failures", and "bad design" categories, I've been working on an open source project to help mitigate those. It's still early and I haven't released it yet, but I have the docs[0] deployed now. If anybody feels like helping us test this early, I'd love some feedback. We're going to be pushing the code live in a week or so. (It's been a lot of building for a while now) I've been thinking about these problems for a while now (as a security engineer) and it's cool to see that my intuition is roughly in line with what OWASP is seeing these days. It's always hard to know if the problems you see people struggling with are representative of the industry as a whole, or if you're just in tunnel vision. Note: We're building this as a company so that we can actually afford to continue doing this full time. I'm still learning how to find the line between open source and a viable business model. Any thoughts would be appreciated[1]! 0: https://www.lunasec.io/docs/ https://www.lunasec.io/docs/ 1: email me at, free at lunasec dot io

red0point 5y ago
Can you tell me how the limitation of the creation of read grants in luna is done?
- freeqaz 5y ago
  We have a few different strategies for this. You can read through the "levels" here[0]. (We need to expand on this doc still) Level 1: There are no grants. Level 2: Access requires a "shared secret" in order to authenticate to the Tokenizer. If you have the secret, get API access to the Tokenizer, and you have a copy of a token, then you can create a grant. In order to use the grant, you also need a valid session for the front-end, but if you have RCE on the back-end then you can get this pretty easily. Level 3: Creating grants also requires presenting a JWT that's signed by an upstream "Auth Provider" that also proxies traffic. This JWT is only able to create grants that are scoped to a specific session (which is identified using a "session id" inside of the JWT). You can still create a grant every token you have access to, but you need to get a valid session to do so. In this design, the proxy strips the cookies from the request and only forwards the JWT, which adds another step to the attack (you have to be able to login to on a browser). This requires that you put your "Root of Trust" into your authentication provider, so you would want to "split" out your authentication/session creation into another service. We have an example app + tutorial explaining this that we'll publish soon. Level 4: You write a separate function,called a "Secure Authorizer", that accepts a session JWT and a Token in order to "authorize" that a grant can be created for a given user. This function is deployed in a hardened container and is difficult to attack (a network restricted Lambda). By adding this layer, you now require that an attacker is able to generate sessions for any user that they want to leak data from. Or you require them to attack the "Secure Authorizer". It's a much more painful attack for an attacker to pull off once you've integrated all of these layers. Does that answer your question? I'll make sure go add this explanation into that levels page. Oh, and thanks for reading the docs! :) 0: https://www.lunasec.io/docs/pages/overview/security/levels/ https://www.lunasec.io/docs/pages/overview/security/levels/

ThePhysicist 5y ago

Interesting that "broken access controls" made it into the top spot. Not sure if this anecdotal but recently I've seen many "hacks" of apps built with external BaaS & auth providers that rely on some kind of token-based authentication, either via JWT or opaque tokens. What happens is that often the providers offer good support for role-based access control but developers just plain ignore it and e.g. include tokens with global read permissions into the app code, or do not properly restrict the permissions of individual tokens, making it possible to e.g. read the whole database with a normal user token. The researcher collective Zerforschung [1] e.g. has uncovered many such incidents. That might have to do with the fact that in my experience those BaaS frameworks and other low-code tools are mostly used by teams with a strong focus on product and UI/UX, which don't have deep security expertise or the right mindset. I think overall outsourcing of aspects like authentication can be beneficial, but only if teams adopt or retain a healthy security awareness as well. [1] https://twitter.com/zerforschung https://twitter.com/zerforschung

thinkharderdev 5y ago
I worked on an identity provider platform and this was always such a huge problem. Many application developers treat authentication as an all or nothing proposition: either a user is authenticated or they are not, but the reality is that authorization is truly hard part and often completely overlooked. This is especially true in Oauth2/OIDC schemes where JWT bearer tokens are issues. At that point you are delegating token validation and access control out to all clients. Even if you are using opaque tokens to prevent basic token verification issues, you still just end up doing the token validation for the client. They still are responsible for access controls on specific resources.
- fendy3002 5y ago
  Out of topic, I use oidc provider (keycloak). I fetch the public key from oidc provider then verify the bearer token with it. Then use the permissions field to authorize users based on their permission. Does my approach correct / suffice?
  - 5y ago

kingkongjaffa 5y ago

I had to go to the github then to https://owasp.org/ https://owasp.org/ to figure our what the heck OWASP even stood for! For those stumbling onto this: The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software.

bibinou 5y ago
on desktop, I see About OWASP in the sidebar: https://owasp.org/Top10/A00-about-owasp/ https://owasp.org/Top10/A00-about-owasp/
- kingkongjaffa 5y ago
  Ahh I see, I did not get that far down the page, I got to https://owasp.org/Top10/A00_2021_Introduction/ https://owasp.org/Top10/A00_2021_Introduction/ and couldn't figure out what OWASP was.
putnambr 5y ago
Every (software engineering) job I've had has had OWASP trainings, if not explicitly listed knowledge and integration of OWASP principles as a job responsibility for levels above entry. What sort of security principles do you follow?

querez 5y ago

The homepage does a very poor job of giving any context, so for those who (like me) who have no clue what they're looking at: This list represents a broad consensus about the most critical security risks to web applications. See https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-top-ten/ for more details (OWASP = "Open Web Application Security Project").

chha 5y ago
Just to give some more context; this is a list that has been updated every 2-4 years since around 2004 or so. A lot of orgs treat it as the minimum a developer needs to know in terms of security, so it's time well spent looking through it (IMO)
jasonlotito 5y ago
On the home page: https://owasp.org https://owasp.org "The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web." About the OWASP Top 10 "The OWASP Top 10 is a book/referential document outlining the 10 most critical security concerns for web application security. The report is put together by a team of security experts from all over the world and the data comes from a number of organisations and is then analysed." Seems pretty spot on to me. And OWASP should be very well known by anyone working in the web field.

ludovicianul 5y ago

I'm honestly happy I see "Insecure Design" into the list. With all the buzzwordy Agileness people often forget that (at least) high level design is important and brings a lot of value if done early on.

Yuioup 5y ago

Is there a hi-res version of the "2017 vs the 2021" image? I'd like to share it with my colleagues. [Edit] Same goes for the other images such as the Venn Diagram.

another-dave 5y ago
They're pretty big images if you open/download them directly — https://owasp.org/Top10/assets/image1.png https://owasp.org/Top10/assets/image1.png https://owasp.org/Top10/assets/image2.png https://owasp.org/Top10/assets/image2.png Not print quality (when you say hi-res, not sure) but definitely readable

gibbiv 5y ago

A few weeks ago I realized OWASP has a top 10 for API security as well. The first version was published in 2019. There are enough differences in API security versus application security to warrant a separate list. However, that project is very light in terms of Docs: https://owasp.org/www-project-api-security/ https://owasp.org/www-project-api-security/

DiffEq 5y ago

Notice the Venn Diagram at the bottom of the page. If you were going to put money in a security solution you would do your best work if you made sure your security related configurations were correct and remained in place. (Least privilege configuration and Change Control). It affects every other category except injection and known vulnerabilities. So then you would make sure you had good life cycle management and patch management to address the issues with software vulnerabilities and then make sure you use Prepared Statements (with Parameterized Queries) or properly constructed Stored Procedures. This is where your focus and money should go before you start doing anything else.

Ekaros 5y ago

Seems like this is still a draft and release will be later this month. Still specially design and CI/CD seem good points to include from security professional's perspective.

Macha 5y ago

I wonder which one the "REST endpoint just JSON serializes and spits out the whole database row" problem falls under now? I previously thought sensitive data exposure included this case.

tptacek 5y ago

The former category for XML External Entities (XXE) is now part of [Security Misconfiguration]. Insecure Deserialization from 2017 is now a part of [Software and Data Integrity Failures] [...] focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. These seem like nonsense statements. XXE's aren't misconfiguration (in any sense that a myriad of other vulnerabilities aren't "misconfigurations" of libraries), and deserialization bugs aren't software update bugs (I don't even know what CI/CD is doing in that description). The OWASP Top 10 is rapidly losing coherence. It's important not to take it too seriously. For all the pantomime about survey data, there's not much real rigor to it. It's mostly a motivational document, and a sort of synecdoche for "all of web app security". The best part of this is the end, where they say "we have no data to support having SSRF on the list, but 'industry people' tell us it's too important not to". Gotta side with the industry people on that one. But maybe you can cram it into "Insecure Design" next year and be rid of it!

mwcampbell 5y ago
> The OWASP Top 10 is rapidly losing coherence. Do you have any recommendations of better resources for web application developers needing to learn about security?

valgor 5y ago

It says "CWE" a lot, but does not say what a "CWE" is. Anyone know?

swid 5y ago
Common Weakness Enumeration - like a public bug report related to security, which is not managed by the developers of the software / hardware. https://cwe.mitre.org/ https://cwe.mitre.org/

benfrancom 5y ago

Another data point referenced in InfoSec circles is the "Verizon Data Breach Investigations Report" https://www.verizon.com/business/resources/reports/dbir/ https://www.verizon.com/business/resources/reports/dbir/