CWE-246 describes a J2EE application that directly uses sockets instead of framework method calls.
According to MITRE, the J2EE standard permits sockets only for talking to legacy systems when no higher level protocol is available.
How it happens
A team needs two components to exchange data. A raw socket looks simple, so they define their own message format. Now they own framing, authentication, encryption, error handling and timeouts.
MITRE's warning is direct: writing your own communication protocol means wrestling with difficult security issues, and without significant scrutiny by a security expert a custom protocol will probably suffer from security problems. The same applies to a custom implementation of a standard protocol. Resources on securing standard protocols exist, but attackers can read them too.
What an attacker gains
The record lists "Other: Quality Degradation". There is no single exploit. The risk is that weaknesses from the other posts in this series, such as incomplete or inconsistent message handling, are easy to introduce in a hand built protocol.
How to find it
MITRE lists automated static analysis. Search J2EE code for direct socket classes outside a documented legacy integration.
How to fix it
The one mitigation in the record, in the Architecture and Design phase: use framework method calls instead of using sockets directly.
If a legacy system truly requires a socket, isolate that code, document why, and have someone with security expertise review it.
Quick check
When does the J2EE standard permit sockets?
Only to communicate with legacy systems when no higher level protocol is available.
