SonarQube

Sonar Qube security rules are classified according to well-established security standards such as: - CWE: SonarQube is a CWE-compatible product since 2015, - OWASP Top 10, - SANS Top 25 (outdated)

Security DSLs provided by the Tool
Name
Description
Security Checks provided by the Tool
Name
Description
Credentials should not be hard-coded.
Components should not be vulnerable to intent redirection.
XML parsers should not allow inclusion of arbitrary files.
Extracting archives should not lead to zip slip vulnerabilities.
Dynamic code execution should not be vulnerable to injection attacks.
NoSQL operations should not be vulnerable to injection attacks.
HTTP request redirections should not be open to forging attacks.
Deserialization should not be vulnerable to injection attacks.
Endpoints should not be vulnerable to reflected cross-site scripting (XSS) attacks.
Database queries should not be vulnerable to injection attacks.
XML parsers should not be vulnerable to XXE attacks.
A secure password should be used when connecting to a database.
XPath expressions should not be vulnerable to injection attacks.
I/O function calls should not be vulnerable to path injection attacks.
LDAP queries should not be vulnerable to injection attacks.
OS commands should not be vulnerable to command injection attacks.
Counter Mode initialization vectors should not be reused.
Thread suspensions should not be vulnerable to Denial of Service attacks.
A new session should be created during user authentication.
JWT should be signed and verified with strong cipher algorithms.
Cipher algorithms should be robust.
Encryption algorithms should be used with secure mode and padding scheme.
Server hostnames should be verified during SSL/TLS connections.
Insecure temporary file creation methods should not be used.
Passwords should not be stored in plain-text or with a fast hashing algorithm.
Server certificates should be verified during SSL/TLS connections.
Persistent entities should not be used as arguments of @RequestMapping methods.
HttpSecurity URL patterns should be correctly ordered.
LDAP connections should be authenticated.
Cryptographic keys should be robust.
Weak SSL/TLS protocols should not be used.
SecureRandom seeds should not be predictable.
Cipher Block Chaining IVs should be unpredictable.
Basic authentication should not be used.
Regular expressions should not be vulnerable to Denial of Service attacks.
HttpServletRequest.getRequestedSessionId() should not be used.
Hashes should include an unpredictable salt.
Accessing files should not lead to filesystem oracle attacks.
Environment variables should not be defined from untrusted input.
XML operations should not be vulnerable to injection attacks.
JSON operations should not be vulnerable to injection attacks.
XML signatures should be validated securely.
XML parsers should not be vulnerable to Denial of Service attacks.
XML parsers should not load external schemas.
Mobile database encryption keys should not be disclosed.
Applications should not create session cookies from untrusted input.
Reflection should not be vulnerable to injection attacks.
Authorizations should be based on strong decisions.
OpenSAML2 should be configured to prevent authentication bypass.
Server-side requests should not be vulnerable to forging attacks.
OS commands should not be vulnerable to argument injection attacks.
ActiveMQConnectionFactory should not be vulnerable to malicious code deserialization.
Logging should not be vulnerable to injection attacks.
Exceptions should not be thrown from servlet methods.
HTTP response headers should not be vulnerable to injection attacks.
Members of Spring components should be injected.
Classes should not be loaded dynamically.