OWASP Top 10
The Open Web Application Security Project (OWASP) maintains a list of what they regard as the Top 10 Web Application Security Risks .
These are listed below, together with an explanation of how CRX deals with them.
- SQL - Prevented by design: The default repository setup neither includes nor requires a traditional database, all data is stored in the content repository. All access is limited to authenticated users and can only be performed through the JCR API. SQL is supported for search queries only (SELECT). Furthemore SQL offers value binding support.
- LDAP - LDAP injection is not possible, since the authentication module filters the input and performs the user import using the bind method.
- OS - There is no shell execution performed from within the application.
2. Cross-Site Scripting (XSS)
The general mitigation practice is to encode all output of user-generated content using a server-side XSS protection library based on OWASP Encoder and AntiSamy .
XSS is a top priority during both testing and development, and any issues found are (typically) resolved immediately.
4. Insecure Direct Object References
All access to data objects is mediated by the repository and therefore restricted by role based access control.
5. Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is mitigated by automatically injecting a cryptographic token into all forms and AJAX requests and verifying this token on the server for every POST.
In addition, AEM ships with a referrer-header based filter, which can be configured to only allow POST requests from specifically white-listed hosts.
6. Security Misconfiguration
It is impossible to guarantee that all software is always correctly configured. However, we strive to provide as much guidance as possible and make configuration as simple as possible. Furthermore, AEM ships with integrated Security Healthchecks that help you monitor security configuration at a glance.
Please review the Security Checklist for more information which provides you with step by step hardening instructions.
7. Insecure Cryptographic Storage
Passwords are stored as cryptographic hashes in the user node; by default such nodes are only readable by the administrator and the user himself.
Sensitive data such as third-party credentials are stored in encrypted form using a FIPS 140-2 certified cryptographic library.
8. Failure to Restrict URL Access
The repository allows the setting of finely-grained privileges (as specified by JCR) for any given user or group at any given path, through access control entries. Access restrictions are enforced by the repository.
9. Insufficient Transport Layer Protection
Mitigated by server configuration (e.g. use HTTPS only).
10. Unvalidated Redirects and Forwards
Mitigated by restricting all redirects to user-supplied destinations to internal locations.