These are listed below, together with an explanation of how CRX deals with them.

1. Injection

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.

3. Broken Authentication and Session Management

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.