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 1: 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?

By default, ASP.NET servers store the HttpSessionState object, its attributes and any objects they reference in memory. This model limits active session state to what can be accommodated by the system memory of a single machine. In order to expand capacity beyond these limitations, servers are frequently configured to persistent session state information, which both expands capacity and permits the replication across multiple machines to improve overall performance. In order to persist its session state, the server must serialize the HttpSessionState object, which requires that all objects stored in it be serializable.

In order for the session to be serialized correctly, all objects the application stores as session attributes must declare the [Serializable] attribute. Additionally, if the object requires custom serialization methods, it must also implement the ISerializable interface.

Example 1: The following class adds itself to the session, but since it is not serializable, the session cannot be serialized correctly.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

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.

If multiple threads are trying to obtain a lock on a resource, calling sleep() while holding a lock can cause all of the other threads to wait for the resource to be released, which can result in degraded performance and deadlock.

Example 1: The following code calls sleep() while holding a lock.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

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
	}
}

Many talented individuals have spent a great deal of time pondering ways to make double-checked locking work in order to improve performance. None have succeeded.

Example 1: At first blush it may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization.

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

The programmer wants to guarantee that only one Fitzer() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called. This idiom is known as double-checked locking.

Unfortunately, it does not work, and multiple Fitzer() objects can be allocated. See The "Double-Checked Locking is Broken" Declaration for more details [1].

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();
}

After a thread signals other threads waiting on a mutex, it must unlock the mutex by calling pthread_mutex_unlock() before another thread can begin running. If the signaling thread fails to unlock the mutex, the pthread_cond_wait() call in the second thread will not return and the thread will not execute.

Example 1: The following code signals another thread waiting on a mutex by calling pthread_cond_signal(), but fails to unlock the mutex the other thread is waiting on.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...