new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

OWASP Cheat Sheets · all subjects

authorization/framework_review

5 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Authorization logic review and custom implementation

Thoroughly review the authorization logic of chosen tools and technologies, implementing custom logic if necessary. Developers have a duty to use frameworks responsibly and wisely. Two general concerns relevant to framework/library selection are misconfiguration/lack of configuration and vulnerabilities within the components themselves. Even in an otherwise securely developed application, vulnerabilities in third-party components can allow attackers to bypass normal authorization controls. Such concerns affect even the most robust and popular libraries and frameworks. Writing complex, secure software is hard, and even the most competent developers make mistakes. Assume any third-party component could be or become subject to an authorization vulnerability.

Dependency management and vulnerability detection

Create, maintain, and follow processes for detecting and responding to vulnerable components. Incorporate tools such as OWASP Dependency Check into the SDLC and consider subscribing to data feeds from vendors, the NVD (National Vulnerability Database), or other relevant sources. Implement defense in depth and do not depend on any single framework, library, technology, or control to be the sole thing enforcing proper access control.

Third-party framework misconfiguration risks

Misconfiguration or complete lack of configuration is a major area in which components developers build upon can lead to broken authorization. These components are typically general-purpose tools made to appeal to a wide audience. For all but the simplest use cases, these frameworks and libraries must be customized or supplemented with additional logic to meet the unique requirements of a particular app or environment. This consideration is especially important when security requirements, including authorization, are concerned.

Framework authorization capability assessment

Take time to thoroughly understand any technology you build authorization logic upon. Analyze the technology's capabilities with the understanding that the authorization logic provided by the component may be insufficient for your application's specific security requirements. Relying on prebuilt logic may be convenient, but this does not mean it is sufficient. Understand that custom authorization logic may well be necessary to meet an app's security requirements. Do not let the capabilities of any library, platform, or framework guide your authorization requirements; rather, authorization requirements should be decided first, then third-party components may be analyzed in light of these requirements.

Framework configuration best practices

Do not rely on default configurations. Test configuration - do not just assume any configuration performed on a third-party component will work exactly as intended in your particular environment. Documentation can be misunderstood, vague, outdated, or simply inaccurate.

Give your agent this brain