Expand my Community achievements bar.

SOLVED

Avoid/block AEM path based servlet post call from postman and curl

Avatar

Level 3

We are using path-based servlets to handle contact form submissions. These endpoints are accessible via tools like Postman and cURL. Our infrastructure includes AEM as a Cloud Service and Akamai CDN. By default, AEM’s CSRF protection does not block requests originating from Postman or cURL. Although we have CSRF configurations implemented in our codebase, these tools can still bypass the protection. We are looking for a way to block such requests. One option is to configure Akamai to block requests based on the User-Agent header, such as those sent by Postman. Could you please suggest the best approach to effectively block these types of requests?

 

{
"filter.enable.safe.user.agents": false,
"filter.methods": [
"DELETE",
"POST",
"PUT"
],
"filter.safe.user.agents": [
"Apache-HttpClient/*",
"Jakarta Commons-HttpClient/*",
"Jakarta-Commons-VFS",
"curl/*",
"Wget/*",
"WebDAVFS/*",
"Microsoft-WebDAV-MiniRedir/*",
"Ruby",
"Adobe-Campaign/*",
"Forms-Mobile *"
],
"filter.excluded.paths": [
"/libs/dam/gui/content/assets/assetlinkshare",
"/content/communities/scorm/RecordResults",
"/bin/api/abc",
"/bin/api/cde",
"/bin/api/efg",
"/bin/api/anb",
"/bin/api/awed",
"/bin/api/asdfg"
]
}
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @neo-silicon,

The clean fix is to let only requests that pass through your CDN reach AEM, and make both Dispatcher and your servlet check for that signal.

Here’s the approach I would follow:

  • Put the form “behind the gate.” Have Akamai add a secret header (e.g., X-CDN-Auth) to real browser submissions when they hit your form path. Attackers hitting origin directly won’t have it.

  • Dispatcher only opens the door for the right knock. Deny POSTs by default, and allow just your submit path if that header is present. Everything else gets a hard block.

  • Servlet double-checks. Before doing any work, your servlet looks for the same header and returns 403 if it’s missing or wrong. That way even if something slips past Dispatcher, AEM still says no.

Add a little hardening so junk traffic doesn’t waste your time:

  • Referrer/Origin checks: Only your site’s domains, and don’t accept empty referrers on POST.

  • Bot/rate limits at Akamai: Throttle bursts and drop obvious bots on the submit path.

  • Human signal: A lightweight CAPTCHA or a short-lived token (nonce) on the form stops simple scripts.

  • Tidy inputs: Only allow expected Content-Types and cap request body size.


Santosh Sai

AEM BlogsLinkedIn


View solution in original post

1 Reply

Avatar

Correct answer by
Community Advisor

Hi @neo-silicon,

The clean fix is to let only requests that pass through your CDN reach AEM, and make both Dispatcher and your servlet check for that signal.

Here’s the approach I would follow:

  • Put the form “behind the gate.” Have Akamai add a secret header (e.g., X-CDN-Auth) to real browser submissions when they hit your form path. Attackers hitting origin directly won’t have it.

  • Dispatcher only opens the door for the right knock. Deny POSTs by default, and allow just your submit path if that header is present. Everything else gets a hard block.

  • Servlet double-checks. Before doing any work, your servlet looks for the same header and returns 403 if it’s missing or wrong. That way even if something slips past Dispatcher, AEM still says no.

Add a little hardening so junk traffic doesn’t waste your time:

  • Referrer/Origin checks: Only your site’s domains, and don’t accept empty referrers on POST.

  • Bot/rate limits at Akamai: Throttle bursts and drop obvious bots on the submit path.

  • Human signal: A lightweight CAPTCHA or a short-lived token (nonce) on the form stops simple scripts.

  • Tidy inputs: Only allow expected Content-Types and cap request body size.


Santosh Sai

AEM BlogsLinkedIn