There is a configuration that permits Kubelets to serve anonymous requests. Anonymous requests are not rejected by any configured authentication method. Because Kubelets are the Kubernetes principal agents to manage a worker machine workload, attackers can use anonymous requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The following configuration file permits a Kubelet to serve anonymous requests because the anonymous field is set to enabled:true.

...
kind: KubeletConfiguration
...
authentication:
  anonymous:
    enabled: true
...

Modern frameworks allow developers to automatically bind HTTP request parameters from both request query and body into model objects for ease of development and increased productivity. If the binder is not correctly configured to control which HTTP request parameters are bound to which model attributes, an attacker may be able to abuse the model binding process and set any other attributes that should not be exposed to user control. This binding is possible even if the model attributes do not appear in the web forms or API contracts.

Example 1: The following Struts 1 DynaActionForm dynamically defines an ActionForm that is bound to user requests. In this case it is used to register an account by providing the account's type and a user's details:

<struts-config>
  <form-beans>
       <form-bean name="dynaUserForm"
          type="org.apache.struts.action.DynaActionForm" >
              <form-property name="type" type="java.lang.String" />
              <form-property name="user" type="com.acme.common.User" />
       </form-bean>
       ...

If registration is successful, the user data will be persisted in the database. The User class is defined as:

public class User {
  private String name;
  private String lastname;
  private int age;
  private Details details;

  // Public Getters and Setters
  ...
}

And the Details class is defined as:

public class Details {
  private boolean is_admin;
  private int id;
  private Date login_date;

  // Public Getters and Setters
  ...
}

Given the scenario in Example 1, an attacker may be able to explore the application and discover that there is a details attribute in the User model. If this is the case, the attacker may then attempt to overwrite the current values assigned to their attributes.
If an attacker can find out these internal attributes, and the framework binder is not correctly configured in order to disallow binding of these attributes, then the attacker would be able to register an administrator account by sending the following request:

type=free&user.name=John&user.lastname=Smith&age=22&details.is_admin=true

It is good programming practice to share a single logger object between all of the instances of a particular class and to use the same logger for the duration of the program.

Example 1: The following statement errantly declares a non-static logger.

private final Logger logger =
            Logger.getLogger(MyClass.class);

Good logging practice dictates the use of a single logger for each class.

Example 1: The following code errantly declares multiple loggers.

public class MyClass {
  private final static Logger good =
            Logger.getLogger(MyClass.class);
  private final static Logger bad =
            Logger.getLogger(MyClass.class);
  private final static Logger ugly =
            Logger.getLogger(MyClass.class);
  ...
}

Example 1: The first Java program that a developer learns to write is the following:

public class MyClass
  ...
    System.out.println("hello world");
  ...
}

While most programmers go on to learn many nuances and subtleties about Java, a surprising number hang on to this first lesson and never give up on writing messages to standard output using System.out.println().

The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.

Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of System.out or System.err may indicate an oversight in the move to a structured logging system.

Typically, you do not want to provide external classes direct access to your object's member fields since a public field can be changed by any external class. Good object oriented designed uses encapsulation to prevent implementation details, such as member fields, from being exposed to other classes. Further, if the system assumes that this field cannot be changed, then malicious code might be able to adversely change the behavior of the system.

Example 1: In the following code, the field ERROR_CODE is declared as public and static, but not final:

public class MyClass
{
public static int ERROR_CODE = 100;
//...
}

In this case, malicious code might be able to change this error code and cause the program to behave in an unexpected manner.

It is common practice to output the values of variables for debugging or testing purposes with code that is not intended to be shipped or remain active in the deployed application. When this sort of debug code is accidentally left in the application, the application might provide information to an attacker in unintended ways. Not all debug statements leak sensitive or private information. However, the presence of a debug statement often indicates that the surrounding code has been neglected and might be in a state of disrepair.