I just got word back from our developers on the threats mentioned in this list, and in general, we want you to know that we that take security issues seriously and test rigorously to ensure those kinds of issues don’t show up. EE is in use by the National Security Agency, several Presidential campaigns, and various government agencies in the United States and the world over. It’s also in use by many Fortune 100 companies. It has passed numerous independent security verification techniques; we just don’t have those on file since firms using EE in the construction of sites initiated those security checks. We are very serious about security and work to ensure that EE is one of the most secure CMS platforms available, but we’re not necessarily using OWASP’s annual top ten list as our litmus test since a site’s security is a combination of EE’s security and the programming acumen of the people building the site. You may want to look at our Security Guidelines that we provide to third-party developers; we follow these guidelines ourselves.
With that said…
* A1: Injection
EE protects against injection by escaping any potentially unsafe data in all the native interactions between requests and the database.
* A2: Cross-Site Scripting (XSS)
XSS protections are indeed put in place within ExpressionEngine.
* A3: Broken Authentication and Session Management
EE has a strong authentication class that handles all session management. Passwords are salted and hashed with a SHA-2 hash function.
* A4: Insecure Direct Object References
Not an issue with EE natively. Site developers need to ensure they’re not opening up this potential threat.
* A5: Cross-Site Request Forgery (CSRF)
EE uses secure forms to protect against CSRF.
* A6: Security Misconfiguration
This is the responsibility of the host to ensure the stack is secure and the developers to ensure security credentials aren’t easily available (e.g., written on notepads).
* A7: Insecure Cryptographic Storage
All passwords are salted and hashed, and no other highly personal information is stored in the database by default. The site developer (and third-party developers) must ensure that any additional opportunities to store sensitive data will be given the necessary precautions.
* A8: Failure to Restrict URL Access
Requiring proper authentication for various parts of the site is available in EE; it’s up to the site developer to properly employ these techniques when building the site.
* A9: Insufficient Transport Layer Protection
This is simply up to the site developer to set the right kind of transport layer protection. If you need a site to require SSL, that’s easy to do. There are plenty of EE sites that run securely with SSL.
* A10: Unvalidated Redirects and Forwards
Much of this is up to the site developer; for EE’s part, we make sure it doesn’t forward the user to places they shouldn’t be. In addition, any links from within the CP automatically go through an intermediate page so that their source (many times the private URL of the CP) doesn’t show up in analytics tools.
I hope this helped answer your questions, Kubik101! Let us know if there’s anything else we can do.