== Why is this an issue?

EJB interceptors provide a way to define code that can be executed before and
after a method call. They are typically used for logging, testing, auditing or
security purposes.

Interceptor methods can be applied or bound at three levels:

* The default interceptor is called for each bean as part of the deployment and
can only be applied through an XML file.

* The class-level interceptor is invoked for each method of the bean. The
class-level interceptor can be applied both through an annotation and through
an XML file.

* The method-level interceptor is invoked for a specific method of the bean.
The method-level interceptor can be applied both through an annotation and
through an XML file.

If you want to declare these methods in an XML file, you must declare them in a
file named `ejb-jar.xml`. Otherwise, they may not be applied or used as
intended.

=== What is the potential impact?

If EJB interceptors are not applied or used as intended, inconsistent
application behavior in the app business logic or security might happen.

Below are some real-world examples of this issue.

==== Inconsistent Behavior

Interceptors declared outside of `ejb-jar.xml` may not be applied consistently
across all EJBs. This can lead to unpredictable application behavior, making
debugging and maintaining the code difficult.

==== Security Risks

Interceptors often handle sensitive operations such as security checks or
transaction management. If an interceptor is not applied due to incorrect
declaration, these operations may not be performed, leading to potential
security vulnerabilities. +
For example, if an interceptor responsible for user authentication is not
applied, unauthorized users may gain access to sensitive information.

==== Performance Impact

Interceptors can also be used to improve application performance, for instance,
by managing database transactions. If these interceptors are not applied, it
could lead to performance issues, such as longer response times or increased
server load.

This could open the way for efficient Denial of Service attacks.

== How to fix it

=== Code examples

==== Noncompliant code example

[source,xml,diff-id=1,diff-type=noncompliant]
----
<!-- ejb-interceptors.xml -->

<assembly-descriptor>
 <interceptor-binding>
      <ejb-name>*</ejb-name>
      <interceptor-class>com.myco.ImportantInterceptor</interceptor-class> <!-- Noncompliant -->
   </interceptor-binding>
</assembly-descriptor>
----

==== Compliant solution

[source,xml,diff-id=1,diff-type=compliant]
----
<!-- ejb-jar.xml -->

<assembly-descriptor>
    <interceptor-binding>
        <ejb-name>*</ejb-name>
        <interceptor-class>com.myco.ImportantInterceptor</interceptor-class>
    </interceptor-binding>
</assembly-descriptor>
----

== Resources

=== Standards

* OWASP - https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[Top 10 2021 Category A5 - Security Misconfiguration]
* OWASP - https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[Top 10 2017 Category A6 - Security Misconfiguration]


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Move this default interceptor to "ejb-jar.xml"


'''
== Comments And Links
(visible only on this page)

=== on 23 Jul 2015, 13:02:01 Ann Campbell wrote:
Rule origin: \https://groups.google.com/forum/#!topic/sonarqube/cYQdBhf00eo


Project is EJB if it contains JEE Beans (any one of javax.ejb.Singleton, MessageDriven, Stateless or Stateful) (@Local/@Remote interfaces are not mandatory)

endif::env-github,rspecator-view[]
