Hey everyone! 👋 I've seen a few threads here about securing modern REST APIs with Radware, but I wanted to share our journey using it to protect a much older, but still critical, part of our stack: our legacy SOAP API.
We have a handful of SOAP endpoints that several key enterprise partners still rely on for order processing. These endpoints were basically sitting ducks—hard to update, full of outdated XML parsing, and a nightmare from a security perspective. We knew we needed a WAF in front of them, and after some evaluation, we landed on Radware.
Here’s a quick walkthrough of our setup and the key lessons learned:
* **Policy Configuration:** The biggest hurdle was crafting the right security policy. Radware’s default templates are great for modern web apps, but we had to create a custom one. We focused heavily on XML threat prevention and tailored the signatures to avoid false positives on our specific SOAP actions.
* **Learning Mode is Crucial:** We put the endpoints behind Radware in "Learning" mode for a full two weeks during normal business traffic. This allowed the system to understand the legitimate XML structure, payload sizes, and parameter patterns. Don't skip this step!
* **Specific Challenges:**
* **WS-Security Headers:** Our partners use WS-Security in the SOAP headers. We had to make sure Radware was inspecting the *decrypted* payload after our on-prem decryptor handled it, which required some specific routing config.
* **Large Payloads:** Some order batches generate huge XML. We adjusted the "Maximum File Size" setting in the XML protection profile to prevent blocking legitimate traffic.
* **False Positives:** The "Cross-site Scripting" rules initially flagged some of our CDATA sections. We created exceptions based on the specific parameter names we use.
The outcome? We've been live for six months with zero legitimate blocks, and Radware has successfully mitigated several attempted XML injection attacks. It's not as "sexy" as protecting a GraphQL API, but it's been rock-solid for our legacy needs.
Has anyone else gone through a similar process with SOAP or other legacy protocols? I'm curious if you tackled the WS-Security piece differently.
– Julie
Data-driven decisions.
Yes! Learning mode was the game-changer for us too. We did a similar two-week ramp, but I'd add that you really need to capture a full business cycle. Our order volume spikes on Mondays and at month-end, and traffic patterns looked completely different. If we'd only learned from mid-week data, we'd have had a mess of false positives when those big XML payloads for batch orders came through.
The only caveat I'd give is not to get *too* comfortable in learning mode. It's easy to leave it on and forget. We set a hard calendar reminder to review and switch to prevention mode, otherwise you're just logging attacks, not stopping them. Did you run any deliberate, safe attack simulations *after* learning to validate your policy before the final cutover?
Sample size matters.