Protecting Your Storefront: Cross-Site Request Forgery (CSRF) in Salesforce Commerce Cloud
Protecting Your Storefront: Cross-Site Request Forgery (CSRF) in Salesforce Commerce Cloud
Introduction
Your storefront handles sensitive user actions—account changes, payments, and personal data submissions. Users expect these actions to be secure and initiated only by them.
But what if an attacker could trick a user’s browser into making these requests without their knowledge—but with their authorization?
That’s Cross-Site Request Forgery (CSRF) in action. To counter this, Salesforce Commerce Cloud provides a CSRF Protection Framework, helping developers secure their storefronts against such attacks.
Unlock SFCC Pro Tips!
Imagine what you’re missing in our other guides! Stay ahead of the competition, get exclusive pro tips, and master Salesforce Commerce Cloud like never before.
👉 Subscribe NOW and never struggle with SFCC again!
The Threats
Directly mitigates CSRF attacks – Prevents unauthorized actions on behalf of users.
Can be bypassed via Cross-Site Scripting (XSS) – If an attacker injects malicious scripts, they could steal CSRF tokens.
Why This Best Practice Matters
CSRF protection is crucial to prevent malicious activities like:
✔️ Unauthorized purchases (users unknowingly buying extra items)
✔️ Address manipulation (orders shipped to fraudulent locations)
How the CSRF Protection Framework Works
SFCC’s CSRF Protection Framework is built on a synchronizer token system:
✅ Generated on SFCC servers – Only validated by the originating server.
✅ Inserted into storefront HTML – Each protected request gets a unique token.
✅ 60-minute validity – Expired tokens are rejected.
✅ Best practice: Send tokens in the POST request body, reducing exposure in logs.
✅ HTTPS enforcement – Ensures encrypted transmission, reducing attack risks.
✅ Only send CSRF tokens to your domain – External sites should never receive them.
⚠️ Important: CSRF tokens rely on the user’s session. They should NOT be used on login forms, as session changes occur during authentication.
CSRF Protection vs. XSS Attacks
CSRF protection is not effective if your site is vulnerable to Cross-Site Scripting (XSS). Attackers can inject scripts to steal CSRF tokens and bypass security.
📌 Key takeaway: Eliminate XSS vulnerabilities to ensure complete CSRF protection.
Bad Practice Example
This form is vulnerable to CSRF because it lacks a security token:
<form action="$URLUtils.http('UserAccount-EditShippingAddress')}" method="POST">
<input type="text" name="user_shipping_street">
<input type="text" name="user_shipping_zip">
<input type="submit" value="Edit Address">
</form> ❌ An attacker could easily trick users into submitting this form without their knowledge.
Best Practice Example
Now, with a CSRF token, the request is protected:
<form action="$URLUtils.http('UserAccount-EditShippingAddress')}" method="POST">
<input type="text" name="user_shipping_street">
<input type="text" name="user_shipping_zip">
<input type="hidden" name="${dw.util.CSRFProtection.getCSRFTokenName()}" value="${dw.util.CSRFProtection.generateCSRFToken()}">
<input type="submit" value="Edit Address">
</form> ✔️ Each request now requires a validated token, blocking CSRF attacks.
📚 More SFCC Security Resources
🔗 Cross-Site Request Forgery
🔗 Class dw.web.CSRFProtection
🔗 Securing Forms in SFRA
🔗 Security Settings in SFCC