header icons

Documentation Rules


Rules are mapped to good and bad practices, as defined by the open-source community. They are computed by open-source rule-checking tools like PMD or FindBugs. They are classified by category associated to some quality characteristics.



  • Avoid Branching Statement As Last In Loop ( AvoidBranchingStatementAsLastInLoop ) provided by PMD Basic Rules 5.1.2

    Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

    This pattern impacts analysability, since the maintainer will have trouble understanding the intended behaviour.

  • Avoid Decimal Literals In BigDecimal Constructor ( AvoidDecimalLiteralsInBigDecimalConstructor ) provided by PMD Basic Rules 5.1.2

    One might assume that the result of 'new BigDecimal(0.1)' is exactly equal to 0.1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding. The (String) constructor, on the other hand, is perfectly predictable: 'new BigDecimal('0.1')' is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.

    This rule impacts product reliability, since the actual number is not the one intended and precision errors may arise.

  • Avoid Deeply Nested If Statements ( AvoidDeeplyNestedIfStmts ) provided by PMD Design Rules 5.1.2

    Avoid creating deeply nested if-then statements since they are harder to read and error-prone to maintain. The nesting threshold can be configured by the user, default value is 3.

    This rule impacts analysability, since deeply nested control structure are hard to understand past a given threshold. It also impacts changeability, since a maintainer will need to check the whole structure to apply a change. It also impacts testability, since it increases the number of paths to check.

  • Avoid Multiple Unary Operators ( AvoidMultipleUnaryOperators ) provided by PMD Basic Rules 5.1.2

    The use of multiple unary operators may be problematic, and/or confusing. Ensure that the intended usage is not a bug, or consider simplifying the expression.

    This rule impacts the reliability, since the pattern has a good probability to be a bug. It also impacts analysability, since such unary operators are unnecessarily complex to understand.

  • Avoid Reassigning Parameters ( AvoidReassigningParameters ) provided by PMD Design Rules 5.1.2

    Reassigning values to incoming parameters is not recommended. Use temporary local variables instead.

    This rule impacts changeability, since the maintainer may assume that the parameters contain the passed values.

  • Avoid Using Hard Coded IP ( AvoidUsingHardCodedIP ) provided by PMD Basic Rules 5.1.2

    Application with hard-coded IP addresses can become impossible to deploy in some cases. Externalizing IP adresses is preferable.

    This pattern impacts changeability, since it is easier to change the IP in an externalised configuration file. It also impacts reusability, since the hard coded IP address may not be adapted to a different usage. It also impacts portability since the hard coded IP address may not be adapted to a different environment (network

  • BC: Impossible cast ( BC_IMPOSSIBLE_CAST ) provided by FindBugs Rules 3.0.0

    This cast will always throw a ClassCastException. FindBugs tracks type information from instanceof checks, and also uses more precise information about the types of values returned from methods and loaded from fields. Thus, it may have more precise information that just the declared type of a variable, and can use this to determine that a cast will always throw an exception at runtime.

    This rule impacts reliability, since an exception will be thrown. It also impacts correctness, since invariably throwing an exception was probably not what was intended.

  • BC: Impossible downcast ( BC_IMPOSSIBLE_DOWNCAST ) provided by FindBugs Rules 3.0.0

    This cast will always throw a ClassCastException. The analysis believes it knows the precise type of the value being cast, and the attempt to downcast it to a subtype will always fail by throwing a ClassCastException.

    This rule impacts reliability, since an exception will be thrown. It also impacts correctness, since invariably throwing an exception was probably not what was intended.

  • Bad Comparison ( BadComparison ) provided by PMD Design Rules 5.1.2

    Avoid equality comparisons with Double.NaN. Due to the implicit lack of representation precision when comparing floating point numbers these are likely to cause logic errors.

    This rule impacts reliability, since the comparison may produce unpredictable behaviour because of the floating precision.

  • Boolean Instantiation ( BooleanInstantiation ) provided by PMD Basic Rules 5.1.2

    Avoid instantiating Boolean objects; you can reference Boolean.TRUE, Boolean.FALSE, or call Boolean.valueOf() instead.

    Boolean instantiation adds unnecessary complexity and clutters the code.

  • Broken NullCheck ( BrokenNullCheck ) provided by PMD Basic Rules 5.1.2

    The null check is broken since it will throw a NullPointerException itself. It is likely that you used || instead of && or vice versa.

    This pattern impacts the reliability, since an exception may be thrown.

  • Class With Only Private Constructors Should Be Final ( ClassWithOnlyPrivateConstructorsShouldBeFinal ) provided by PMD Design Rules 5.1.2

    A class with only private constructors should be final, unless the private constructor is invoked by a inner class.

    This rule impacts analysability, since the maintainer will have trouble understanding the intent of the class.

  • Close Resource ( CloseResource ) provided by PMD Design Rules 5.1.2

    Ensure that resources (like Connection, Statement, and ResultSet objects) are always closed after use.

    Makes sure you close your database connections. It does this by looking for code patterned like this: Connection c = X; try { // do stuff, and maybe catch something } finally { c.close(); }

    This rule impacts resources usage, since unneeded open connections take some memory and cpu.

  • Confusing Ternary ( ConfusingTernary ) provided by PMD Design Rules 5.1.2

    Avoid negation within an 'if' expression with an 'else' clause. For example, rephrase: if (x != y) diff(); else same(); as: if (x == y) same(); else diff(); Most 'if (x != y)' cases without an 'else' are often return cases, so consistent use of this rule makes the code easier to read. Also, this resolves trivial ordering problems, such as 'does the error case go first?' or 'does the common case go first?'.

    This rule impacts analysability.

  • Constructor Calls Overridable Method ( ConstructorCallsOverridableMethod ) provided by PMD Design Rules 5.1.2

    Calling overridable methods during construction poses a risk of invoking methods on an incompletely constructed object and can be difficult to debug. It may leave the sub-class unable to construct its superclass or forced to replicate the construction process completely within itself, losing the ability to call super(). If the default constructor contains a call to an overridable method, the subclass may be completely uninstantiable. Note that this includes method calls throughout the control flow graph - i.e., if a constructor Foo() calls a private method bar() that calls a public method buz(), this denotes a problem.

    Searches through all methods and constructors called from constructors. It marks as dangerous any call to overridable methods from non-private constructors. It marks as dangerous any calls to dangerous private constructors from non-private constructors.

    This rule impacts reliability, since the object may not be fully initialised. It may throw exceptions or cause an unpredictable behaviour.

  • DMI: Bad constant value for month ( DMI_BAD_MONTH ) provided by FindBugs Rules 3.0.0

    This code passes a constant month value outside the expected range of 0..11 to a method.

    This rule impacts correctness, since the result is not what was intended.

  • DMI: Collections should not contain themselves ( DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES ) provided by FindBugs Rules 3.0.0

    This call to a generic collection's method would only make sense if a collection contained itself (e.g., if s.contains(s) were true). This is unlikely to be true and would cause problems if it were true (such as the computation of the hash code resulting in infinite recursion). It is likely that the wrong value is being passed as a parameter.

    This rule impacts correctness, since the result is not what was intended.

  • Dm: Hardcoded constant database password ( DMI_CONSTANT_DB_PASSWORD ) provided by FindBugs Rules 3.0.0

    This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can easily learn the password.

  • Dm: Empty database password ( DMI_EMPTY_DB_PASSWORD ) provided by FindBugs Rules 3.0.0

    This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password.

  • DMI: Invocation of hashCode on an array ( DMI_INVOKING_HASHCODE_ON_ARRAY ) provided by FindBugs Rules 3.0.0

    The code invokes hashCode on an array. Calling hashCode on an array returns the same value as System.identityHashCode, and ignores the contents and length of the array. If you need a hashCode that depends on the contents of an array a, use java.util.Arrays.hashCode(a).

    This rule impacts correctness, since the result is not what was intended.

  • DMI: Double.longBitsToDouble invoked on an int ( DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT ) provided by FindBugs Rules 3.0.0

    The Double.longBitsToDouble method is invoked, but a 32 bit int value is passed as an argument. This almostly certainly is not intended and is unlikely to give the intended result.

    This rule impacts correctness, since the result is not what was intended.

  • DMI: Vacuous call to collections ( DMI_VACUOUS_SELF_COLLECTION_CALL ) provided by FindBugs Rules 3.0.0

    This call doesn't make sense. For any collection c, calling c.containsAll(c) should always be true, and c.retainAll(c) should have no effect.

    This rule impacts correctness, since the result is not what was intended.

  • Dont Use Float Type For Loop Indices ( DontUseFloatTypeForLoopIndices ) provided by PMD Basic Rules 5.1.2

    Don't use floating point for loop indices: the termination test may misbehave due to floating point granularity. If you must use floating point, use double unless you're certain that float provides enough precision and you have a compelling performance need (space or time).

    This rule impacts reliability, since the loop may terminate at an unexpected time.

  • Double Checked Locking ( DoubleCheckedLocking ) provided by PMD Basic Rules 5.1.2

    Partially created objects can be returned by the Double Checked Locking pattern when used in Java. An optimizing JRE may assign a reference to the baz variable before it creates the object the reference is intended to point to. For more details refer to: http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html

    The double check pattern impacts reliability, since the code may produce a crash or unpredictable behaviour when the half-defined class is used.

  • EC: equals() used to compare array and nonarray ( EC_ARRAY_AND_NONARRAY ) provided by FindBugs Rules 3.0.0

    This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem to be an array. If things being compared are of different types, they are guaranteed to be unequal and the comparison is almost certainly an error. Even if they are both arrays, the equals method on arrays only determines of the two arrays are the same object. To compare the contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).

    This rule impacts correctness, since the result is not what was intended.

  • EC: equals(...) used to compare incompatible arrays ( EC_INCOMPATIBLE_ARRAY_COMPARE ) provided by FindBugs Rules 3.0.0

    This method invokes the .equals(Object o) to compare two arrays, but the arrays are of incompatible types (e.g., String[] and StringBuffer[], or String[] and int[]). They will never be equal. In addition, when equals(...) is used to compare arrays it only checks to see if they are the same array, and ignores the contents of the arrays.

    This rule impacts correctness, since the result is not what was intended.

  • Eq: equals method always returns false ( EQ_ALWAYS_FALSE ) provided by FindBugs Rules 3.0.0

    This class defines an equals method that always returns false. This means that an object is not equal to itself, and it is impossible to create useful Maps or Sets of this class. More fundamentally, it means that equals is not reflexive, one of the requirements of the equals method.

    The likely intended semantics are object identity: that an object is equal to itself. This is the behavior inherited from class Object. If you need to override an equals inherited from a different superclass, you can use use:

    public boolean equals(Object o) { return this == o; }

    This rule impacts correctness, since the result is not what was intended. It also impacts reusability, since the reflexive requirement is not met and other developers will assume it is.

  • Eq: equals() method always returns true ( EQ_ALWAYS_TRUE ) provided by FindBugs Rules 3.0.0

    This class defines an equals method that always returns true. This is imaginative, but not very smart. Plus, it means that the equals method is not symmetric.

    This rule impacts correctness, since the result is not what was intended. It also impacts reusability, since the reflexive requirement is not met and other developers will assume it is.

  • Empty Catch Block ( EmptyCatchBlock ) provided by PMD Empty Rules 5.1.2

    Empty Catch Block finds instances where an exception is caught, but nothing is done. In most circumstances, this swallows an exception which should either be acted on or reported.

    This rule impacts reliability, since nothing is done about the exception and unpredictable behaviour may occur.

  • FE: Doomed test for equality to NaN ( FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER ) provided by FindBugs Rules 3.0.0

    This code checks to see if a floating point value is equal to the special Not A Number value (e.g., if (x == Double.NaN)). However, because of the special semantics of NaN, no value is equal to Nan, including NaN. Thus, x == Double.NaN always evaluates to false. To check to see if a value contained in x is the special Not A Number value, use Double.isNaN(x) (or Float.isNaN(x) if x is floating point precision).

    This rule impacts correctness, since the result is not what was intended.

  • FL: Method performs math using floating point precision ( FL_MATH_USING_FLOAT_PRECISION ) provided by FindBugs Rules 3.0.0

    The method performs math operations using floating point precision. Floating point precision is very imprecise. For example, 16777216.0f + 1.0f = 16777216.0f. Consider using double math instead.

    This rule impacts correctness, since the result is not what was intended.

  • God Class ( GodClass ) provided by PMD Design Rules 5.1.2

    The God Class rule detects the God Class design flaw using metrics. God classes do too many things, are very big and overly complex. They should be split apart to be more object-oriented. The rule uses the detection strategy described in 'Object-Oriented Metrics in Practice'. The violations are reported against the entire class. See also the references: Michele Lanza and Radu Marinescu. Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. Springer, Berlin, 1 edition, October 2006. Page 80.

    This rule impacts analysability, since an overly complex class is difficult to read. It also impact changeability, since separating the various fonctionalities of the class may be difficult.

  • This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.

    FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriouslyconsider using a commercial static analysis or pen-testing tool.

  • HRS: HTTP Response splitting vulnerability ( HRS_REQUEST_PARAMETER_TO_HTTP_HEADER ) provided by FindBugs Rules 3.0.0

    This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.

    FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriouslyconsider using a commercial static analysis or pen-testing tool.

  • Jumbled Incrementer ( JumbledIncrementer ) provided by PMD Basic Rules 5.1.2

    Avoid jumbled loop incrementers - it is usually a mistake, and is confusing even if intentional.

    It impacts changeability, since modifying the loop will probably have some side-effects. It also impacts reliability by increasing the complexity of code, thus inducing more opportunities for bugs.

  • Misplaced Null Check ( MisplacedNullCheck ) provided by PMD Basic Rules 5.1.2

    The null check here is misplaced. If the variable is null a NullPointerException will be thrown. Either the check is useless (the variable will never be 'null') or it is incorrect.

    This pattern impacts the reliability, since an exception may be thrown. It also impacts analysability, since the maintainer will take unnecessary time to understand that the null is misplaced.

  • Missing Break In Switch ( MissingBreakInSwitch ) provided by PMD Design Rules 5.1.2

    Switch statements without break or return statements for each case option may indicate problematic behaviour. Empty cases are ignored as these indicate an intentional fall-through.

    This rule impacts reliability, since an unpredictable behaviour may arise when unintendedly falling through the next case. It also impacts changeability, since introducing a new case may modify the behaviour of the previous one.

  • Non Case Label In Switch Statement ( NonCaseLabelInSwitchStatement ) provided by PMD Design Rules 5.1.2

    A non-case label (e.g. a named break/continue label) was present in a switch statement. This is legal, but confusing. It is easy to mix up the case labels and the non-case labels.

    This rule impacts analysability, since this may confuse the maintainer when reading the switch. By the way, introducing a label in the switch creates an intricate control flow and is discouraged.

  • Non Static Initializer ( NonStaticInitializer ) provided by PMD Design Rules 5.1.2

    A non-static initializer block will be called any time a constructor is invoked (just prior to invoking the constructor). While this is a valid language construct, it is rarely used and is confusing.

    This rule impacts analysability, since a maintainer will look for the constructor as the first chunk of code executed.

  • Non Thread Safe Singleton ( NonThreadSafeSingleton ) provided by PMD Design Rules 5.1.2

    Non-thread safe singletons can result in bad state changes. Eliminate static singletons if possible by instantiating the object directly. Static singletons are usually not needed as only a single instance exists anyway. Other possible fixes are to synchronize the entire method or to use an initialize-on-demand holder class (do not use the double-check idiom). See Effective Java, item 48.

    This rule impacts reliability, since bad state changes may induce an unpredictable behaviour.

  • Override Both Equals And Hash code ( OverrideBothEqualsAndHashcode ) provided by PMD Basic Rules 5.1.2

    Override both public boolean Object.equals(Object other), and public int Object.hashCode(), or override neither. Even if you are inheriting a hashCode() from a parent class, consider implementing hashCode and explicitly delegating to your superclass.

    Even if at some time only one of these methods is indeed used, a maintainer will assume that the code is consistent, i.e. the hashCode and equals functions are both overriden to fit the new behaviour.

  • PT: Absolute path traversal in servlet ( PT_ABSOLUTE_PATH_TRAVERSAL ) provided by FindBugs Rules 3.0.0

    The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory. See http://cwe.mitre.org/data/definitions/36.html for more information.

    FindBugs looks only for the most blatant, obvious cases of absolute path traversal. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about absolute path traversal, you should seriously consider using a commercial static analysis or pen-testing tool.

  • PT: Relative path traversal in servlet ( PT_RELATIVE_PATH_TRAVERSAL ) provided by FindBugs Rules 3.0.0

    The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory. See http://cwe.mitre.org/data/definitions/23.html for more information.

    FindBugs looks only for the most blatant, obvious cases of absolute path traversal. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about absolute path traversal, you should seriously consider using a commercial static analysis or pen-testing tool.

  • Position Literals First In Case Insensitive Comparisons ( PositionLiteralsFirstInCaseInsensitiveComparisons ) provided by PMD Design Rules 5.1.2

    Position literals first in comparisons, if the second argument is null then NullPointerExceptions can be avoided, they will just return false.

    This rule impacts reliability, since a NullPointerException will arise if the object is null.

  • Position Literals First In Comparisons ( PositionLiteralsFirstInComparisons ) provided by PMD Design Rules 5.1.2

    Position literals first in comparisons, if the second argument is null then NullPointerExceptions can be avoided, they will just return false.

    This rule impacts reliability, since a NullPointerException will arise if the object is null.

  • Preserve Stack Trace ( PreserveStackTrace ) provided by PMD Design Rules 5.1.2

    Throwing a new exception from a catch block without passing the original exception into the new exception will cause the original stack trace to be lost making it difficult to debug effectively.

    This rule impacts analysability, since the original exception trace is lost.

  • Return From Finally Block ( ReturnFromFinallyBlock ) provided by PMD Basic Rules 5.1.2

    Avoid returning from a finally block, this can discard exceptions.

    It impacts reliability because the caught exception may hide another unseen exception.

  • Se: Non-serializable class has a serializable inner class ( SE_BAD_FIELD_INNER_CLASS ) provided by FindBugs Rules 3.0.0

    This Serializable class is an inner class of a non-serializable class. Thus, attempts to serialize it will also attempt to associate instance of the outer class with which it is associated, leading to a runtime error. If possible, making the inner class a static inner class should solve the problem. Making the outer class serializable might also work, but that would mean serializing an instance of the inner class would always also serialize the instance of the outer class, which it often not what you really want.

    This rule impacts reliability, since an exception will occur when attempting to serialise the inner class.

  • Se: Non-serializable value stored into instance field of a serializable class ( SE_BAD_FIELD_STORE ) provided by FindBugs Rules 3.0.0

    A non-serializable value is stored into a non-transient field of a serializable class.

    This rule impacts reliability, since an exception will occur when attempting to serialise the inner class.

  • Se: Class is Serializable but its superclass doesn't define a void constructor ( SE_NO_SUITABLE_CONSTRUCTOR ) provided by FindBugs Rules 3.0.0

    This class implements the Serializable interface and its superclass does not. When such an object is deserialized, the fields of the superclass need to be initialized by invoking the void constructor of the superclass. Since the superclass does not have one, serialization and deserialization will fail at runtime.

    This rule impacts reliability, since an exception will be thrown at runtime when deserialising the object.

  • Se: Class is Externalizable but doesn't define a void constructor ( SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION ) provided by FindBugs Rules 3.0.0

    This class implements the Externalizable interface, but does not define a void constructor. When Externalizable objects are deserialized, they first need to be constructed by invoking the void constructor. Since this class does not have one, serialization and deserialization will fail at runtime.

    This rule impacts reliability, since an exception may be thrown at runtime when deserialising the object.

  • Switch Statements Should Have Default ( SwitchStmtsShouldHaveDefault ) provided by PMD Design Rules 5.1.2

    All switch statements should include a default option to catch any unspecified values.

    This rule impacts reliability, since an unpredictable behaviour may result if the switch value was not intended.

  • Unconditional If Statement ( UnconditionalIfStatement ) provided by PMD Basic Rules 5.1.2

    Do not use if statements that are always true or always false.

    A maintainer will have trouble understanding why an unconditional if has been used. It further clutters the code.

  • FS: Format string placeholder incompatible with passed argument ( VA_FORMAT_STRING_BAD_ARGUMENT ) provided by FindBugs Rules 3.0.0

    The format string placeholder is incompatible with the corresponding argument. For example, System.out.println("%d ", "hello"); The %d placeholder requires a numeric argument, but a string value is passed instead. A runtime exception will occur when this statement is executed.

    This rule impacts reliability, since the pattern will throw an exception when executed.

  • FS: The type of a supplied argument doesn't match format specifier ( VA_FORMAT_STRING_BAD_CONVERSION ) provided by FindBugs Rules 3.0.0

    One of the arguments is uncompatible with the corresponding format string specifier. As a result, this will generate a runtime exception when executed. For example, String.format("%d", "1") will generate an exception, since the String "1" is incompatible with the format specifier %d.

    This rule impacts reliability, since the pattern will throw an exception when executed.

  • FS: Illegal format string ( VA_FORMAT_STRING_ILLEGAL ) provided by FindBugs Rules 3.0.0

    The format string is syntactically invalid, and a runtime exception will occur when this statement is executed.

    This rule impacts reliability, since the pattern will throw an exception when executed.

  • FS: Format string references missing argument ( VA_FORMAT_STRING_MISSING_ARGUMENT ) provided by FindBugs Rules 3.0.0

    Not enough arguments are passed to satisfy a placeholder in the format string. A runtime exception will occur when this statement is executed.

    This rule impacts reliability, since the pattern will throw an exception when executed.

  • FS: No previous argument for format string ( VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT ) provided by FindBugs Rules 3.0.0

    The format string specifies a relative index to request that the argument for the previous format specifier be reused. However, there is no previous argument. For example, formatter.format("%<s %s", "a", "b") would throw a MissingFormatArgumentException when executed.

    This rule impacts reliability, since the pattern will throw an exception when executed.

  • XSS: JSP reflected cross site scripting vulnerability ( XSS_REQUEST_PARAMETER_TO_JSP_WRITER ) provided by FindBugs Rules 3.0.0

    This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

    FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.

  • XSS: Servlet reflected cross site scripting vulnerability in error page ( XSS_REQUEST_PARAMETER_TO_SEND_ERROR ) provided by FindBugs Rules 3.0.0

    This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

    FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.

  • XSS: Servlet reflected cross site scripting vulnerability ( XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER ) provided by FindBugs Rules 3.0.0

    This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

    FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.