diff --git a/geode-docs/tools_modules/http_session_mgmt/session_security_filter.html.md.erb b/geode-docs/tools_modules/http_session_mgmt/session_security_filter.html.md.erb
index 2632826cc8d..d6f01abce33 100644
--- a/geode-docs/tools_modules/http_session_mgmt/session_security_filter.html.md.erb
+++ b/geode-docs/tools_modules/http_session_mgmt/session_security_filter.html.md.erb
@@ -28,20 +28,20 @@ Apache Geode HTTP Session Management uses Java serialization to store session at
**Key Benefits:**
- **Application-Level Security**: Each web application defines its own security policy
-- **Zero-Downtime Configuration**: Changes take effect on WAR deployment, no cluster restart required
+- **Zero-Downtime Configuration**: Changes take effect on WAR deployment and no cluster restart is required
- **Defense in Depth**: Explicit allowlist prevents gadget chain attacks
-- **Backward Compatible**: Existing applications continue to work without configuration
+- **Backward Compatibility**: Existing applications continue to work without configuration
## Security Warning
+**Always configure a deserialization filter for production deployments.**
+
**Without a configured filter, session deserialization has NO restrictions.** Any serializable class can be deserialized, leaving your application vulnerable to:
- Remote Code Execution (RCE)
- Denial of Service (DoS)
- Arbitrary object instantiation attacks
-**Always configure a deserialization filter for production deployments.**
-
## Basic Configuration
### Step 1: Add Filter Pattern to web.xml
@@ -66,7 +66,7 @@ Add a context parameter to your application's `web.xml`:
### Step 2: Deploy WAR File
-Deploy or redeploy your WAR file to the application server. The filter takes effect immediately—no cluster restart required.
+Deploy or redeploy your WAR file to the application server. The filter takes effect immediately and no cluster restart is required.
## Pattern Syntax
@@ -76,7 +76,7 @@ The filter pattern follows [JEP 290](https://openjdk.org/jeps/290) syntax:
|---------|---------|
| `com.myapp.**` | Allow all classes in `com.myapp` package and subpackages |
| `com.myapp.model.User` | Allow specific class only |
-| `java.lang.**` | Allow all classes in `java.lang` package |
+| `java.lang.**; java.util.**; java.time.**` | Allow essential Java packages |
| `!com.dangerous.**` | Explicitly reject package (takes precedence) |
| `!*` | Reject everything else (default deny) |
@@ -220,10 +220,10 @@ java.time.**;
After configuring the filter:
-1. Test all session operations (create, read, update, delete)
-2. Verify session attributes deserialize correctly
-3. Test session failover scenarios
-4. Monitor logs for `ObjectInputFilter` rejections
+1. Test all session operations (create, read, update, delete).
+2. Verify that the session attributes deserialize correctly.
+3. Test session failover scenarios.
+4. Monitor logs for `ObjectInputFilter` rejections.
## Troubleshooting
@@ -242,9 +242,9 @@ After configuring the filter:
```
-### Filter Not Taking Effect
+### Filter Not Working
-**Symptom:** Filter pattern changes don't apply
+**Symptom:** Filter pattern changes are not applied
**Solution:**
@@ -294,14 +294,10 @@ After configuring the filter:
### Backward Compatibility
**Without Filter Configuration:**
-- Sessions continue to work as before
-- No breaking changes
-- No security protection (vulnerable)
+Sessions continue to work as they did prior. There are no breaking changes. There is no security protection (vulnerable).
**With Filter Configuration:**
-- Explicit security policy enforced
-- Only allowed classes can be deserialized
-- Protected against deserialization attacks
+Explicit security policy is enforced. Only allowed classes can be deserialized. You are protected against deserialization attacks.
## Security Reference