If a method is overridden by a child class, the child class can bypass security checks in the parent class.
Example 1: In the following code, doSecurityCheck() performs a security check and can be overridden by a child class.

public class BadSecurityCheck {
    private int id;

    public BadSecurityCheck() {
        doSecurityCheck();
        id = 1;
    }
    protected void doSecurityCheck() {
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            sm.checkPermission(new SomePermission("SomeAction"));
        }
    }
}

In this example, if the SecurityManager permission is not allowed, a SecurityException exception will be thrown, which is a runtime exception and will stop the program from executing any further. Since BadSecurityCheck is not final, and the method doSecurityCheck() is protected and not final, it means that this class can be subclassed to override this function.

Example 2: In the following code, doSecurityCheck() is overridden by a subclass:

public class EvilSubclass extends BadSecurityCheck {
    private int id;

    public EvilSubclass() {
        super();
    }
    protected void doSecurityCheck() {
        //do nothing
    }
}

When EvilSubclass is instantiated, the constructor first calls super(), to invoke the constructor of the superclass. This in turn calls the function doSecurityCheck(), but Java will first look for the function within the subclass prior to looking in the superclass, thus invoking the attacker controlled method that bypasses the security check, so id will still be set to 1.

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.

Example 1: The following transport binding uses HTTP instead of HTTPS:

<sp:TransportBinding>
  <wsp:Policy>
    <sp:TransportToken>
      <wsp:Policy>
        <sp:HttpToken/>
       </wsp:Policy>
    </sp:TransportToken>
    ...
</sp:TransportBinding>