EJB Bad Practices: Use of Sockets

Draft Variant
Structure: Simple
Description

This vulnerability occurs when an Enterprise JavaBeans (EJB) component breaks the EJB specification by directly creating or using network sockets.

Extended Description

The EJB specification sets clear rules to ensure components are portable and behave consistently across different application servers. One of these rules explicitly forbids EJB beans from acting as network servers—meaning they must not open sockets to listen for or accept incoming connections. This restriction preserves the server's ability to manage resources, control the bean's lifecycle, and maintain transactional integrity. Allowing an EJB to become a socket server conflicts with its primary role as a managed component serving EJB clients. It can destabilize the container, interfere with clustering and load balancing, and create unpredictable security and performance issues. Instead, socket-based server functionality should be implemented outside the EJB container, in a managed service or a dedicated layer, keeping the bean's design aligned with its intended client-serving architecture.

Common Consequences 1
Scope: Other

Impact: Quality Degradation

Potential Mitigations 1
Phase: Architecture and DesignImplementation
Do not use Sockets when writing EJBs.
Demonstrative Examples 1
The following Java example is a simple stateless Enterprise JavaBean that retrieves stock symbols and stock values. The Enterprise JavaBean creates a socket and listens for and accepts connections from clients on the socket.

Code Example:

Bad
Java
java
And the following Java example is similar to the previous example but demonstrates the use of multicast socket connections within an Enterprise JavaBean.

Code Example:

Bad
Java
java
The previous two examples within any type of Enterprise JavaBean violate the EJB specification by attempting to listen on a socket, accepting connections on a socket, or using a socket for multicast.
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • Software Fault Patterns