The values of attributes for Oracle ADF Faces components can ordinarily be set only on the server. However, a number of components allow the developer to define a list of attributes that can be set on the client. unsecure attribute of these components can specify such a list.

Currently, the only attribute that can appear inside the unsecure attribute is disabled, and it allows the client to define which components are enabled and which ones are not. It is never a good idea to let the client control the values of attributes that should only be settable on the server.

Example: The following code demonstrates an inputText component that collects password information from the user and uses the unsecure attribute.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Cookies are strictly a HTTP mechanism as per RFC 2109. There should be no reasonable expectation for them to work for protocols other than HTTP, including file://. It is not clear what their behavior should be, and what rules of security compartmentalization should apply. For example, should HTML files downloaded to local disk from the Internet share the same cookies as any HTML code installed locally?

ASP.NET Core middleware that is not added to the middleware pipeline in the correct order will not function as intended, leaving an application open to a variety of security issues.

Example 1: The UseCookiePolicy() method adds the cookie policy middleware to the middleware pipeline, allowing for customized cookie policies. When specified in the wrong order as shown, any cookie policy stated by the programmer will be ignored.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

ASP.NET Core middleware that is not added to the middleware pipeline in the correct order will not function as intended, leaving an application open to a variety of security issues.

Example 1: The UseHttpsRedirection() method adds HTTPS redirection middleware to the middleware pipeline, which allows for redirection of insecure HTTP requests to a secure HTTPS request. When specified in the wrong order as shown, no meaningful HTTPS redirection will occur before processing the request through the middleware listed before the redirect. This will allow for HTTP requests to be processed by the application before being redirected to the secure HTTPS connection.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

ASP.NET Core middleware that is not added to the middleware pipeline in the correct order will not function as intended, leaving an application open to a variety of security issues.

Example 1: The UseHttpLogging() method adds HTTP logging middleware to the middleware pipeline which allows middleware components to log. When specified in the wrong order as shown, no middleware added to the pipeline before the call to UseHttpLogging() will log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Example 2: The UseWC3Logging() method adds W3C logging middleware to the middleware pipeline which allows middleware components to log. When specified in the wrong order as shown, no middleware added to the pipeline before the call to UseWC3Logging() will log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

ASP.NET MVC controller actions that modify data by writing, updating, or deleting could benefit from being restricted to accept one of the following HTTP verbs: Post, Put, Patch, or Delete. This increases the difficulty of cross-site request forgery because accidental clicking of links will not cause the action to execute.

The following controller action by default accepts any verb and may be susceptible to cross-site request forgery:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

Using a model class that has properties that are required (as marked with the [Required] attribute) and properties that are optional (as not marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains more data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

Having mixed requiredness without explicitly communicating which parameters are to be model-bound may indicate that there are model properties for internal use but can be controlled by attacker.

The following code defines a possible model class that has properties that have [Required] and properties that do not have [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

If any optional parameters can change the behavior of an application, then an attacker may be able to actually change that behavior by communicating an optional parameter in a request.

Using a model class that has non-nullable properties that are required (as marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

If a model has a required non-nullable parameter and an attacker does not communicate that required parameter in a request -- that is, the attacker uses an under-posting attack -- then the property will have the default value (usually zero) which will satisfy the [Required] validation attribute. This may produce unexpected application behavior.

The following code defines a possible model class that has a required enum, which is non-nullable:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

If a model class has required property and is the type of an optional member of a parent model class, it may be susceptible to under-posting attacks if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties, including submodels.

If a submodel is optional -- that is, the parent model has a property without the [Required] attribute -- and if an attacker does not communicate that submodel, then the parent property will have a null value and the required fields of the child model will not be asserted by model validation. This is one form of an under-posting attack.

Consider the following the model class definitions:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

If an attacker does not communicate a value for the ParentModel.Child property, then the ChildModel.RequiredProperty property will have a [Required] which is not asserted. This may produce unexpected and undesirable results.

According to Apple's policy, the application should always explain to users why their fingerprints are required. Failing to do so may confuse the user or even get your app rejected from the AppStore.

Example 1: The following code uses Touch ID to authenticate the user but fails to provide a localized reason that explains why the authentication is required:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Even if castor creates a lock on an object it does not prevent other threads from reading or writing to it. Read-only queries are also about 7 times faster compared with default shared mode.

Example 1: The following example specifies the query mode as SHARED which allows both read and write access.

results = query.execute(Database.SHARED);

By default Castor executes queries in shared mode. Since shared mode allows both read and write access, it is unclear what kind of operation the query is intended for. If the object is going to be used in a read-only context, shared access adds unnecessary performance overhead.

Example 1: The following example does not specify a query mode.

results = query.execute();    //missing query mode

At some point in every .NET developer's career, a problem surfaces that appears to be so mysterious, impenetrable, and impervious to debugging that there seems to be no alternative but to blame the garbage collector. Especially when the bug is related to time and state, there may be a hint of empirical evidence to support this theory: inserting a call to GC.Collect() sometimes seems to make the problem go away.

In almost every case we have seen, calling GC.Collect() is the wrong thing to do. In fact, calling GC.Collect() can cause performance problems if it is invoked too often.

At some point in every Java developer's career, a problem surfaces that appears to be so mysterious, impenetrable, and impervious to debugging that there seems to be no alternative but to blame the garbage collector. Especially when the bug is related to time and state, there may be a hint of empirical evidence to support this theory: inserting a call to System.gc() sometimes seems to make the problem go away.

In almost every case we have seen, calling System.gc() is the wrong thing to do. In fact, calling System.gc() can cause performance problems if it is invoked too often.

When comparing objects, developers usually want to compare properties of objects. However, calling equals() on a class (or any super class/interface) that does not explicitly implement equals() results in a call to the equals() method inherited from java.lang.Object. Instead of comparing object member fields or other properties, Object.equals() compares two object instances to see if they are the same. Although there are legitimate uses of Object.equals(), it is often an indication of buggy code.

Example 1:

public class AccountGroup
{
	private int gid;

	public int getGid()
	{
		return gid;
	}

	public void setGid(int newGid)
	{
		gid = newGid;
	}
}
...
public class CompareGroup
{
	public boolean compareGroups(AccountGroup group1, AccountGroup group2)
	{
		return group1.equals(group2);   //equals() is not implemented in AccountGroup
	}
}

The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize() [1].

Example 1: The following method omits the call to super.finalize().

protected void finalize() {
  discardNative();
}

Code Correctness: Incorrect Serializable Method Signature issues occur when a serializable class creates a serialization or deserialization function but does not follow the correct signatures:

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

Deviating from the method signatures that serialization requires may mean that the method is never called during serialization/deserialization, leading to incomplete serialization/deserialization, or could mean that untrusted code could gain access to the objects.
In the case that there are exceptions that are not thrown, it may mean that serialization/deserialization fails and crashes the application or potentially even fails quietly such that objects may be only partially constructed correctly, leading to flaws that can be extremely difficult to debug. The caller should catch these exceptions such that incorrect serialization/deserialization can be handled properly without a crash or partially constructed objects.

Forwarding an HttpServletRequest, redirecting an HttpServletResponse, or flushing the servlet's output stream buffer causes the associated stream to commit. Any subsequent buffer resets or stream commits, such as additional flushes or redirects, will result in IllegalStateExceptions.

Furthermore, Java servlets allow data to be written to the response stream using either ServletOutputStream or PrintWriter, but not both. Calling getWriter() after having called getOutputStream(), or vice versa, will also cause an IllegalStateException.



At runtime, an IllegalStateException prevents the response handler from running to completion, effectively dropping the response. This can cause server instability, which is a sign of an improperly implemented servlet.

Example 1: The following code redirects the servlet response after its output stream buffer has been flushed.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

Example 2: Conversely, the following code attempts to write to and flush the PrintWriter's buffer after the request has been forwarded.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

In most cases, setting the Content-Length header of a request indicates a developer is interested in
communicating the length of the POST data sent to the server. However, this header should be 0 or a
positive integer.

Example 1: The following code will set an incorrect Content-Length.

  URL url = new URL("http://www.example.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

In most cases, a call to toString() on an array indicates a developer is interested in returning the contents of the array as a String. However, a direct call to toString() on an array will return a string value containing the array's type and hashcode in memory.
Example 1: The following code will output [Ljava.lang.String;@1232121.

String[] strList = new String[5];
...
System.out.println(strList);