📢 Attention Salesforce Certified Trailblazers! Maintain your credentials and link your Trailhead and Webassessor accounts by April 19th. Learn more.

Discover Built-in XSS Protections in Lightning Platform

Learning Objectives

After completing this unit, you'll be able to:
  • Understand how Salesforce protects developers against cross-site scripting with automatic HTML.
  • Learn the locations where automatic HTML is not applied and where developers can disable it.
  • List the different locations where XSS commonly appears in Lightning Platform applications.

Lightning Platform XSS Protections

In the previous unit, you learned all about XSS and some common methodologies for preventing it in web applications. We discussed the two general approaches to XSS protection: input filtering and output encoding. So what does Salesforce do to protect your apps?

As a platform, Salesforce offers its customers and developers maximum flexibility for accessing and storing data. Were we to employ input filtering, we might strip out vital information from our customers’ data against their wishes. So the Salesforce approach to XSS defense is 100% output encoding. We don’t control what you place on our platform, but wherever possible we make sure it’s displayed securely. In fact, by default all merge fields are automatically HTML encoded!

In this unit, we’ll go into more detail on how this default protection works. We’ll also discuss gaps that you’ll need to be aware of and account for in your applications.

Automatic HTML Encoding

As we mentioned previously, Salesforce automatically HTML encodes any values and merge fields placed in HTML context. This includes all standard functionality, as well as Visualforce pages and components

Here’s an example.

<apex:outputText value="{!$CurrentPage.parameters.userName}" />

Theoretically, this piece of code is vulnerable to XSS because user-supplied input is reflected back in the context of the page. However, thanks to the Lightning Platform, this code isn’t vulnerable! If the URL was /page?userName=<script>, you'd see this on the page.


If you inspected the source code of the page, you'd see this.


The platform changed "<" and "<" into "&lt;" and "&gt;" by automatically HTML encoding the special characters. The platform treats the data as text, not code.

Disabling Automatic HTML Encoding

While it’s great that Salesforce provides this functionality for developers out of the box, there are certain use cases where you want to have raw HTML embedded in the page. To support this, several Visualforce tags have an optional attribute called “escape.” To disable automatic encoding, you set “escape” to false.

Here’s an example.

<apex:outputText escape="false">
    Hello {!$CurrentPage.parameters.userName}

While disabling encoding may be necessary for certain use cases, you should exercise extreme caution. If you disable automatic encoding, you have to rely on other XSS prevention techniques (like whitelisting) to ensure that your code isn’t vulnerable to XSS.

Salesforce Default Protections in Different Execution Contexts

The platform automatically HTML encodes merge fields, but only in an HTML context. So, to leverage this protection correctly, you need a thorough understanding of how user-controlled variables are rendered by the browser.

HTML Context

    {!$CurrentPage.parameters.userInput} <! -- safe (auto HTML Encoded) -->

Although user input is inserted into HTML context, this statement is safe because the platform automatically HTML encodes the input.

    {!$CurrentPage.parameters.userInput} <! -- safe (auto HTML Encoded) -->

As before, user input inserted into HTML context is safe because the platform automatically HTML encodes it.

Keep in mind that the auto encoding only provides HTML encoding of <, >, and quotes within HTML attributes. So if your application passes through multiple parsing contexts, this protection isn’t fully sufficient.

<div onclick=”console.log(‘{!$CurrentPage.parameters.userInput}’)”>Click me!</div>

In the above code sample, userInput is rendered with a JavaScript execution context embedded with an HTML context. The auto-HTML encoding alone is insufficient.

Script Context

When inserting merge fields into JavaScript, watch out for XSS vulnerabilities. Take a look at this example.

    var x = ‘{!$CurrentPage.parameters.userInput}’; // vulnerable to XSS

Here user input is inserted into script context, so the value isn’t automatically encoded and is vulnerable to XSS.

Style Context

CSS (cascading style sheets) is an increasingly complex language that is slowly becoming standardized across browsers. Modern browsers don’t allow JavaScript injection within CSS attribute values. However, some older browsers do. As a result, be careful about utilizing merge fields within a style context.

    .foo {
        Color: #{!CurrentPage.parameters.userInput}; // vulnerable to XSS

In the code above, the default automatic HTML encoding doesn’t apply and the application is vulnerable to XSS.

Next Steps with XSS

While Lightning Platform protects developers from XSS in some basic use cases, there are cases (<script> tags, <style> tags, and action handlers, for example) where developers need to do their own encoding to make sure their applications aren’t vulnerable.

Salesforce gives developers encoding functions so they can do just that. In the next unit, we’ll walk through how this works in more detail and learn how to properly fix these different use cases.


Flower icon used to indicate that the content is for Salesforce Classic

Remember, this module is meant for Salesforce Classic. When you launch your hands-on org, switch to Salesforce Classic to complete this challenge.