Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarLint
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarCloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube

Secrets
ABAP
Ansible
Apex
AzureResourceManager
C
C#
C++
CloudFormation
COBOL
CSS
Dart
Docker
Flex
Go
HTML
Java
JavaScript
JCL
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Scala
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML

Java static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your JAVA code

Filtered: 131 rules found

cwe

Impact

Clean code attribute

Credentials should not be hard-coded
Vulnerability
Extracting archives should not lead to zip slip vulnerabilities
Vulnerability
Server-side templates should not be vulnerable to injection attacks
Vulnerability
Dynamic code execution should not be vulnerable to injection attacks
Vulnerability
NoSQL operations should not be vulnerable to injection attacks
Vulnerability
HTTP request redirections should not be open to forging attacks
Vulnerability
Deserialization should not be vulnerable to injection attacks
Vulnerability
Endpoints should not be vulnerable to reflected cross-site scripting (XSS) attacks
Vulnerability
Database queries should not be vulnerable to injection attacks
Vulnerability
A secure password should be used when connecting to a database
Vulnerability
XPath expressions should not be vulnerable to injection attacks
Vulnerability
I/O function calls should not be vulnerable to path injection attacks
Vulnerability
LDAP queries should not be vulnerable to injection attacks
Vulnerability
OS commands should not be vulnerable to command injection attacks
Vulnerability
Double-checked locking should not be used
Bug
Hard-coded secrets are security-sensitive
Security Hotspot
Hard-coded passwords are security-sensitive
Security Hotspot
Switch cases should end with an unconditional "break" statement
Code Smell
Counter Mode initialization vectors should not be reused
Vulnerability
Thread suspensions should not be vulnerable to Denial of Service attacks
Vulnerability
A new session should be created during user authentication
Vulnerability
JWT should be signed and verified with strong cipher algorithms
Vulnerability
Cipher algorithms should be robust
Vulnerability
Encryption algorithms should be used with secure mode and padding scheme
Vulnerability
Server hostnames should be verified during SSL/TLS connections
Vulnerability
Insecure temporary file creation methods should not be used
Vulnerability
Passwords should not be stored in plaintext or with a fast hashing algorithm
Vulnerability
Server certificates should be verified during SSL/TLS connections
Vulnerability
Persistent entities should not be used as arguments of "@RequestMapping" methods
Vulnerability
LDAP connections should be authenticated
Vulnerability
Cryptographic keys should be robust
Vulnerability
Weak SSL/TLS protocols should not be used
Vulnerability
Secure random number generators should not output predictable values
Vulnerability
Cipher Block Chaining IVs should be unpredictable
Vulnerability
Regular expressions should not be vulnerable to Denial of Service attacks
Vulnerability
"HttpServletRequest.getRequestedSessionId()" should not be used
Vulnerability
Password hashing functions should use an unpredictable salt
Vulnerability
Jump statements should not occur in "finally" blocks
Bug
Using slow regular expressions is security-sensitive
Security Hotspot
Using publicly writable directories is security-sensitive
Security Hotspot
Using clear-text protocols is security-sensitive
Security Hotspot
Accessing Android external storage is security-sensitive
Security Hotspot
Receiving intents is security-sensitive
Security Hotspot
Broadcasting intents is security-sensitive
Security Hotspot
Expanding archive files without controlling resource consumption is security-sensitive
Security Hotspot
Using weak hashing algorithms is security-sensitive
Security Hotspot
Using unsafe Jackson deserialization configuration is security-sensitive
Security Hotspot
Setting JavaBean properties is security-sensitive
Security Hotspot
Disabling CSRF protections is security-sensitive
Security Hotspot
Using non-standard cryptographic algorithms is security-sensitive
Security Hotspot
Using pseudorandom number generators (PRNGs) is security-sensitive
Security Hotspot
"null" should not be returned from a "Boolean" method
Code Smell
Fields in a "Serializable" class should either be transient or serializable
Code Smell
"switch" statements should have "default" clauses
Code Smell
"Object.finalize()" should remain protected (versus public) when overriding
Code Smell
Server-side requests should not be vulnerable to traversing attacks
Vulnerability
Accessing files should not lead to filesystem oracle attacks
Vulnerability
Environment variables should not be defined from untrusted input
Vulnerability
XML operations should not be vulnerable to injection attacks
Vulnerability
JSON operations should not be vulnerable to injection attacks
Vulnerability
Mobile database encryption keys should not be disclosed
Vulnerability
Applications should not create session cookies from untrusted input
Vulnerability
Reflection should not be vulnerable to injection attacks
Vulnerability
Authorizations should be based on strong decisions
Vulnerability
Server-side requests should not be vulnerable to forging attacks
Vulnerability
Strings and Boxed types should be compared using "equals()"
Bug
Blocks should be synchronized on "private final" fields
Bug
Non-serializable objects should not be stored in "javax.servlet.http.HttpSession" instances
Bug
"toString()" and "clone()" methods should not return null
Bug
"InterruptedException" and "ThreadDeath" should not be ignored
Bug
Classes should not be compared by name
Bug
"Thread.run()" should not be called directly
Bug
The "Object.finalize()" method should not be called
Bug
Enabling file access for WebViews is security-sensitive
Security Hotspot
Enabling JavaScript support for WebViews is security-sensitive
Security Hotspot
Constructing arguments of system commands from user input is security-sensitive
Security Hotspot
Using unencrypted files in mobile applications is security-sensitive
Security Hotspot
Using biometric authentication without a cryptographic solution is security-sensitive
Security Hotspot
Using unencrypted databases in mobile applications is security-sensitive
Security Hotspot
Authorizing non-authenticated users to use keys in the Android KeyStore is security-sensitive
Security Hotspot
Allowing user enumeration is security-sensitive
Security Hotspot
Allowing requests with excessive content length is security-sensitive
Security Hotspot
Disabling auto-escaping in template engines is security-sensitive
Security Hotspot
Allowing deserialization of LDAP objects is security-sensitive
Security Hotspot
Setting loose POSIX file permissions is security-sensitive
Security Hotspot
Formatting SQL queries is security-sensitive
Security Hotspot
"@Deprecated" code marked for removal should never be used
Code Smell
"Integer.toHexString" should not be used to build hexadecimal strings
Code Smell
Multiline blocks should be enclosed in curly braces
Code Smell
Unused assignments should be removed
Code Smell
Throwable and Error should not be caught
Code Smell
Track uses of "FIXME" tags
Code Smell
Assignments should not be made from within sub-expressions
Code Smell
Generic exceptions should never be thrown
Code Smell
OS commands should not be vulnerable to argument injection attacks
Vulnerability
"ActiveMQConnectionFactory" should not be vulnerable to malicious code deserialization
Vulnerability
Logging should not be vulnerable to injection attacks
Vulnerability
Exceptions should not be thrown from servlet methods
Vulnerability
Return values should not be ignored when they contain the operation status code
Bug
Math operands should be cast before assignment
Bug
"equals(Object obj)" and "hashCode()" should be overridden in pairs
Bug
Disclosing fingerprints from web application technologies is security-sensitive
Security Hotspot
Having a permissive Cross-Origin Resource Sharing policy is security-sensitive
Security Hotspot
Delivering code in production with debug features activated is security-sensitive
Security Hotspot
Searching OS commands in PATH is security-sensitive
Security Hotspot
Allowing both safe and unsafe HTTP methods is security-sensitive
Security Hotspot
Creating cookies without the "HttpOnly" flag is security-sensitive
Security Hotspot
Creating cookies without the "secure" flag is security-sensitive
Security Hotspot
Mutable fields should not be "public static"
Code Smell
"@Deprecated" code should not be used
Code Smell
"public static" fields should be constant
Code Smell
Classes that override "clone" should be "Cloneable" and call "super.clone()"
Code Smell
Class variable fields should not have public accessibility
Code Smell
Track uses of "TODO" tags
Code Smell
XML parsers should not be vulnerable to XXE attacks
Vulnerability
Resources should be closed
Bug
Exit methods should not be called
Code Smell
Zero should not be a possible denominator
Bug
Locks should be released on all paths
Bug
Equality operators should not be used in "for" loop termination conditions
Code Smell
Optional value should only be accessed after calling isPresent()
Bug
Conditionally executed code should be reachable
Bug
Null pointers should not be dereferenced
Bug
Limited dependence should be placed on operator precedence
Code Smell
Boolean expressions should not be gratuitous
Code Smell
"NullPointerException" should not be caught
Code Smell
Exception handlers should preserve the original exceptions
Code Smell
"@NonNull" values should not be set to null
Bug
Private mutable members should not be stored or returned directly
Code Smell
"Exception" should not be caught when not required by called methods
Code Smell
"==" and "!=" should not be used when "equals" is overridden
Code Smell

Throwable and Error should not be caught

consistency - conventional

maintainability

Code Smell

MajorSonarSource default severity
click to learn more

cwe
error-handling
bad-practice
cert

Why is this an issue?

More Info

Throwable is the superclass of all errors and exceptions in Java. Error is the superclass of all errors, which are not meant to be caught by applications.

Catching either Throwable or Error will also catch OutOfMemoryError and InternalError, from which an application should not attempt to recover.

Noncompliant code example

try { /* ... */ } catch (Throwable t) { /* ... */ }
try { /* ... */ } catch (Error e) { /* ... */ }

Compliant solution

try { /* ... */ } catch (RuntimeException e) { /* ... */ }
try { /* ... */ } catch (MyException e) { /* ... */ }

Available In:

Catch issues on the fly,
in your IDE

Detect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

Analyze code in your
on-premise CI

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Sonar helps developers write Clean Code.
Privacy Policy | Cookie Policy

In-IDE

SaaS

Self-Hosted