Re: Add documentation to address OWASP Top 10?

Proposed text: Take a look at the Open Web Application Security Project (OWASP) Top 10 list which identifies some common vulnerabilities in web applications. While Django has tools to address some of the issues, other issues must be

Re: Add documentation to address OWASP Top 10?

> Den 6. apr. 2016 kl. 07.29 skrev Anssi Kääriäinen : > > It is notable that if the number of items is a secret (say, you don't > want to reveal how many sales items you have), just having information > about sequential numbers is bad. In that case you should use UUID, >

Re: Add documentation to address OWASP Top 10?

On 06/04/16 11:35, Josh Smeaton wrote: I like the idea of addressing the OWASP top 10. Further, I think the advice of obscuring keys is wrong. The problem is actually addressed in the OWASP Top 10[0] *4 Insecure Direct Object References:* A direct object reference occurs when a developer

Re: Add documentation to address OWASP Top 10?

That was my thinking as well. This is a basic topic when it comes to web security. We can point to the OWASP 10 but I don’t think it’s reasonable cram a complete course about web security into Django’s documentation, let alone maintain it. Django’s docs will never contain everything one may

Re: Add documentation to address OWASP Top 10?

It is notable that if the number of items is a secret (say, you don't want to reveal how many sales items you have), just having information about sequential numbers is bad. In that case you should use UUID, which the documentation could point out. On Wed, Apr 6, 2016 at 4:35 AM, Josh Smeaton

Re: Add documentation to address OWASP Top 10?

I like the idea of addressing the OWASP top 10. Further, I think the advice of obscuring keys is wrong. The problem is actually addressed in the OWASP Top 10[0] *4 Insecure Direct Object References:* A direct object reference occurs when a developer exposes a reference to an internal

Add documentation to address OWASP Top 10?

>From a Trac ticket [0]: "Using incremental URLs (i.e. /comment/1 is the first comment and /comment/2 is the second comment, respectively for base 64 or other counting systems) is highly dangerous for private information. You could simply get all of the, say, private comments by accessing all