Biometric authentication should not be performed without an associated CryptoObject
value.
This code appears to use an XMLReader
instance without setting the correct input processing flags. This could allow XML External Entity (XXE) attacks to easily occur.
execute
or addBatch
method on an SQL statement JAVA-S0082The method invokes the execute
or addBatch
method on an SQL statement with a String
that seems to be dynamically generated. This can allow SQL injection attacks to occur.
DocumentBuilder
may be vulnerable to XXE attacks JAVA-A1052This code appears to use a DocumentBuilder
instance without setting the correct input processing flags. This could allow XML External Entity (XXE) attacks to easily occur.
The code creates an SQL prepared statement from a String
that was formed dynamically. This may be vulnerable to SQL injection attacks.
This Spring security configuration appears to store passwords in plaintext or hashed with a weak hashing algorithm. This could allow an attacker to easily steal user login information.
Configure Spring to store passwords securely.
This code stores a reference to an externally mutable object into a static field. If unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. It may be possible for external code to inspect or change the value of the static field by holding a reference to it after passing it to this class.
A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. This is dangerous because it could allow external code to modify the behavior of the class by changing data asssumed to be invariant.
Returning a reference to a mutable value stored in any of an object's fields exposes the internal state of the object. This could lead to an injection vulnerability.
This code stores a reference to an externally mutable object as part of the internal state of the object. This can allow an injection attack to occur.
A new cookie is created without the Secure
flag set to true
. The Secure
flag is a browser directive that prevents the cookie from being transmitted over insecure connections (http://
).
Intents that contain sensitive information should only be broadcast as explicit intents with tight control on what activities may receive them.
The code creates an SQL prepared statement from a String
that was formed dynamically. This may be vulnerable to SQL injection attacks.
This code appears to create an XMLStreamReader using an XMLInputFactory instance without setting the correct input processing flags. This could allow XML External Entity (XXE) attacks to easily occur.
An overly permissive CORS policy can allow malicious actors to retrieve sensitive data from your own servers through the client.
This servlet uses an HTTP request parameter to construct a path. While this action may mean to access only one directory in the server's file system, it does not properly neutralize sequences such as ".."
that can resolve to a location that is outside that directory.
ECB
and CBC
encryption modes are both known to be insecure due to a number of attacks that they make possible. As the default encryption mode in Java is ECB, this issue will be raised if only the algorithm is specified in a cipher transformation.
The ciphertext produced is susceptible to alteration by an adversary. This means that the cipher provides no way to detect that the data has been tampered with. If the ciphertext can be controlled by an attacker, it could be altered without detection.
XSSRequestWrapper
is an HTTPRequestWrapper
implementation that attempts to strip out potential XSS vulnerabilities from request data, and has been circulated through a number of blogs over the years. Unfortunately its implementation suffers from a number of design defects. These render it a weak protection, and even contribute towards facilitating certain attacks.
Using XSSRequestWrapper
is not recommended due to its defective design.
Implementing a custom hashing algorithm can be error-prone and could allow for collision-based attacks on hashed data. Avoid implementing your own hash function, and use only trusted implementations.