A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application.

In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface.

Example 1: The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.

JWT is a standard used to create a URL-safe means of transferring data between two parties. JWT provides protection against data tampering because the information it contains is digitally signed with either the HMAC or the RSA algorithm. The server typically generates JWT after successful authentication by the client. This JWT accompanies future client requests to the server for stateless authentication. These tokens are often targeted by malicious users for impersonation attacks. The JWT specification includes various protection mechanisms to prevent the tokens against such attacks. The jti claim provides a unique identifier for the JWT. It can be used to prevent the JWT from being replayed. The application "signs out" the user from all devices by deleting all JWTs in the backend store associated with that user. In addition, the developer should use exp (expiration time) to expire the JWT.

An authorization server that can be used to generate multiple valid access tokens with the same authorization code is susceptible to impersonation attacks.
The OAuth2 API makes it possible for users to grant access to their accounts with an authorization server. When a user has denied access for an application, all access tokens are revoked and become invalid. However, if the associated authorization token is not revoked, a malicious application can exploit it to restore access to user's account after access revocation.

Authorization servers that do not verify the client_id and client_secret when refreshing the access_token are susceptible to impersonation and unauthorized access attacks. Authorization servers might issue refresh tokens to web application clients and native application clients. The authorization server must verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, the authorization server should deploy other means to detect refresh token abuse such as redirecting the user to repeat the authorization process after an expiration date is reached.

OAuth2 protocol implementations that do not use the state parameter value with sufficient entropy are susceptible to a CSRF vulnerability that might give an attacker the ability to login to the victim's current application account using a third-party account without any restrictions.
In authorization code type and implicit grant type, the OAuth2 protocol is vulnerable to a CSRF attack if the state parameter value is predictable. An attacker can perform a normal OAuth2 process and get the redirection URL that contains the authorization code for the third-party. The attacker can bind their own account to the victim's account for the vulnerable application by enticing a victim to access this URL. If the state parameter is set in the redirection URL but without sufficient entropy, then an attacker can predict the user's state parameter and forge a reliable redirection URL to persuade the victim to access and then implement a CSRF attack.

Values associated with block.timestamp or block.number are often used by developers to trigger time-dependent events, however, these values often give a sense of time that is generally not safe to use.

Due to the decentralized nature of blockchain, nodes can synchronize time only to a certain degree. Using block.timestamp is unreliable at best, and at worst, malicious miners can alter the timestamp of their blocks if they see an advantage to do so.

As for block.number, even though it is possible to predict the time between blocks (approximately 14 seconds), block times are not constant and can vary depending on network activity. This makes block.number unreliable for time-related calculations.

Example 1: The following code uses block.number to unlock funds after a certain period of time.

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}