High Traffic to /libs/granite/csrf/token.json and /libs/granite/security/currentuser.json in AEM – How to Optimize? | Community
Skip to main content
G
georhe6
Level 4
March 27, 2026
Question

High Traffic to /libs/granite/csrf/token.json and /libs/granite/security/currentuser.json in AEM – How to Optimize?

  • March 27, 2026
  • 1 reply
  • 21 views

Hi Team,

We are observing a very high volume of requests hitting AEM internal Granite APIs:

  • /libs/granite/csrf/token.json (~618K requests, ~19%)
  • /libs/granite/security/currentuser.json (~300K requests, ~9.3%)

Together, these endpoints account for nearly 29% of total traffic in our logs.

We understand these endpoints are used for authentication/session handling, but this volume seems unusually high and is impacting overall traffic patterns.

We would like guidance on:

  1. Is this level of traffic expected for these endpoints in Adobe Experience Manager (especially Cloud Service)?
  2. What are the recommended best practices to reduce or optimize calls to these APIs?
         
  • Dispatcher/CDN rules?
  • Frontend implementation improvements?

 

  1. Could this indicate a misconfiguration (e.g., frequent polling, missing caching, or bot traffic)?
  2. Are there Adobe-recommended patterns to minimize repeated CSRF token and current user calls?

  3. Any insights or similar experiences would be really helpful.

    Thanks in advance!

    1 reply

    R
    ruchith53
    Level 2
    March 28, 2026

    Hi ​@georhe6,

    This level of traffic does not reflect an optimal implementation. 

     

    Calls to “/libs/granite/csrf/token.json” should ideally be limited to "One per user session", as the CSRF token is session based and does not need to be fetched repeatedly.

    Similarly, “/libs/granite/security/currentuser.json” should only be invoked when user information is actually required, rather than on every request or component load. 

     

    And yes, frequent polling introduces unnecessary load on the system and is not recommended. Instead, go with caching or event-driven approaches. It is recommended to implement client side caching, preferably using session storage so that values persist across the user session without repeated API calls. This helps to reduce unnecessary traffic. 

     

    If the current implementation involves multiple components independently making authentication related calls, it would be more efficient to refactor this into a centralized approach, where a single service manages CSRF tokens and user data. 

     

    Additionally, if required implement rate limiting per IP at the CDN layer.

     

    Note: Both “/libs/granite/security/currentuser.json” and “/libs/granite/csrf/token.json” must not be cached at the CDN or Dispatcher level, because they contain per-user/session data which are dynamic.

    Terms & ConditionsAccessibility statement

    Loading footer...