What it is: J2EE Bad Practices: Non-serializable Object Stored in Session (CWE-579) is a type of reliability issue that occurs when non-serializable objects are stored in HttpSession attributes.
Why it matters: This can lead to quality degradation and issues with session replication, impacting the overall reliability of your application.
How to fix it: Ensure all objects stored in session attributes implement the Serializable interface.
TL;DR: J2EE Bad Practices: Non-serializable Object Stored in Session (CWE-579) is a reliability issue that occurs when non-serializable objects are stored in HttpSession attributes, leading to quality degradation. Ensure all objects stored in session attributes implement the Serializable interface.
| Field | Value |
|---|---|
| CWE ID | CWE-579 |
| OWASP Category | Not directly mapped |
| CAPEC | None known |
| Typical Severity | Medium |
| Affected Technologies | Java EE, J2EE, Servlets |
| Detection Difficulty | Moderate |
| Last Updated | 2026-07-29 |
What is J2EE Bad Practices: Non-serializable Object Stored in Session?
J2EE Bad Practices: Non-serializable Object Stored in Session (CWE-579) is a type of reliability issue that occurs when non-serializable objects are stored as HttpSession attributes. As defined by the MITRE Corporation under CWE-579, and classified by the OWASP Foundation under [mapping]…
Quick Summary
J2EE Bad Practices: Non-serializable Object Stored in Session (CWE-579) is a reliability issue that occurs when non-serializable objects are stored as HttpSession attributes. This can lead to quality degradation and issues with session replication, impacting the overall reliability of your application.
Jump to: Quick Summary · J2EE Bad Practices: Non-serializable Object Stored in Session Overview · How J2EE Bad Practices: Non-serializable Object Stored in Session Works · Business Impact of J2EE Bad Practices: Non-serializable Object Stored in Session · J2EE Bad Practices: Non-serializable Object Stored in Session Attack Scenario · How to Detect J2EE Bad Practices: Non-serializable Object Stored in Session · How to Fix J2EE Bad Practices: Non-serializable Object Stored in Session · Framework-Specific Fixes for J2EE Bad Practices: Non-serializable Object Stored in Session · How to Ask AI to Check Your Code for J2EE Bad Practices: Non-serializable Object Stored in Session · J2EE Bad Practices: Non-serializable Object Stored in Session Best Practices Checklist · J2EE Bad Practices: Non-serializable Object Stored in Session FAQ · Vulnerabilities Related to J2EE Bad Practices: Non-serializable Object Stored in Session · References · Scan Your Own Site
J2EE Bad Practices: Non-serializable Object Stored in Session Overview
What: A reliability issue that occurs when non-serializable objects are stored as HttpSession attributes.
Why it matters: This can lead to quality degradation and issues with session replication, impacting the overall reliability of your application.
Where it occurs: In Java EE applications that use HttpSession for state management without ensuring proper serialization support.
Who is affected: Developers and organizations using Java EE frameworks like J2EE, Servlets, etc., where non-serializable objects are stored in session attributes.
How J2EE Bad Practices: Non-serializable Object Stored in Session Works
Root Cause
The root cause lies in storing non-serializable objects within session attributes without ensuring that these objects implement the Serializable interface.
Attack Flow
- An application stores a non-serializable object as an HttpSession attribute.
- The session replication process fails due to the inability to serialize and deserialize the object.
- This leads to reliability issues in maintaining consistent state across replicated sessions.
Prerequisites to Exploit
- Non-serializable objects stored in HttpSession attributes.
- Session replication enabled without proper serialization support.
Vulnerable Code
public void storeNonSerializableObjectInSession(HttpServletRequest request, HttpServletResponse response) {
MyCustomClass customObj = new MyCustomClass();
request.getSession().setAttribute("customAttribute", customObj);
}
This code stores a non-serializable object (MyCustomClass) in the session attribute without implementing the Serializable interface.
Secure Code
public void storeSerializableObjectInSession(HttpServletRequest request, HttpServletResponse response) {
MySerializableClass serializableObj = new MySerializableClass();
request.getSession().setAttribute("customAttribute", serializableObj);
}
This code ensures that only objects implementing the Serializable interface are stored in session attributes.
Business Impact of J2EE Bad Practices: Non-serializable Object Stored in Session
Quality Degradation: Issues with session replication and reliability impact overall application quality.
Financial
- Potential downtime costs.
- Increased maintenance overhead.
Compliance
- Non-compliance with security standards that mandate reliable state management.
J2EE Bad Practices: Non-serializable Object Stored in Session Attack Scenario
- An attacker identifies a Java EE application storing non-serializable objects in session attributes.
- The attacker exploits the issue by triggering session replication failures, leading to unreliable application behavior.
- This results in poor user experience and potential data inconsistencies.
How to Detect J2EE Bad Practices: Non-serializable Object Stored in Session
Manual Testing
- Review code for instances where non-serializable objects are stored as HttpSession attributes.
- Ensure all session attributes implement the Serializable interface.
Automated Scanners (SAST / DAST)
Static analysis tools can detect instances of non-serializable objects being stored in session attributes. Dynamic testing is required to confirm behavior during runtime.
PenScan Detection
PenScan’s scanner engines like ZAP, Nuclei, Wapiti, Nikto, SSLyze, and Dalfox can identify potential issues with session replication reliability.
False Positive Guidance
False positives may occur if non-serializable objects are stored but properly handled through other mechanisms (e.g., transient fields).
How to Fix J2EE Bad Practices: Non-serializable Object Stored in Session
- Ensure all objects stored in HttpSession attributes implement the Serializable interface.
- Use proper serialization and deserialization techniques for session replication.
Framework-Specific Fixes for J2EE Bad Practices: Non-serializable Object Stored in Session
Java
public void storeSerializableObjectInSession(HttpServletRequest request, HttpServletResponse response) {
MySerializableClass serializableObj = new MySerializableClass();
request.getSession().setAttribute("customAttribute", serializableObj);
}
How to Ask AI to Check Your Code for J2EE Bad Practices: Non-serializable Object Stored in Session
Review the following Java code block for potential CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session vulnerabilities and rewrite it using proper serialization techniques:
J2EE Bad Practices: Non-serializable Object Stored in Session Best Practices Checklist
✅ Ensure all objects stored in HttpSession attributes implement the Serializable interface. ✅ Use proper serialization and deserialization techniques for session replication.
J2EE Bad Practices: Non-serializable Object Stored in Session FAQ
How does J2EE Bad Practices: Non-serializable Object Stored in Session occur?
It occurs when a non-serializable object is stored in an HttpSession attribute, which can lead to issues with session replication and reliability.
Why should I be concerned about J2EE Bad Practices: Non-serializable Object Stored in Session?
This vulnerability can cause quality degradation by impacting the reliability of your application’s session management.
How does J2EE Bad Practices: Non-serializable Object Stored in Session affect my business?
It may lead to financial losses, compliance issues, and damage to your reputation if not addressed promptly.
What is the root cause of J2EE Bad Practices: Non-serializable Object Stored in Session?
The root cause lies in storing non-serializable objects within session attributes without ensuring that these objects implement the Serializable interface.
How can I detect J2EE Bad Practices: Non-serializable Object Stored in Session manually?
Manually check your code for instances where non-serializable objects are stored as HttpSession attributes and ensure they implement the Serializable interface.
What is a real-world example of J2EE Bad Practices: Non-serializable Object Stored in Session?
An example would be storing an instance of a custom class that does not implement Serializable within the session, leading to issues during replication.
How can I prevent J2EE Bad Practices: Non-serializable Object Stored in Session from occurring?
Ensure all objects stored in HttpSession attributes implement the Serializable interface and are properly serialized before being stored.
Vulnerabilities Related to J2EE Bad Practices: Non-serializable Object Stored in Session
| CWE | Name | Relationship |
|---|---|---|
| 573 | Improper Following of Specification by Caller (ChildOf) |
References
Scan Your Own Site
Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find J2EE Bad Practices: Non-serializable Object Stored in Session and other risks before an attacker does.