Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Run Health Check

Learning Objectives

After completing this unit, you’ll be able to:

  • Explain how Health Check can keep your org secure.
  • Use Health Check configurations to improve the security of apps running in your Salesforce org.

Salesforce Platform Security and Custom Apps

When you build custom apps to run on your Salesforce org, it’s important to ensure that your Salesforce instance is secure, in addition to securing the apps themselves. Since the majority of custom applications are business-specific, the apps you build will likely be specific to your Salesforce org.

Salesforce constantly strives to make our platform as secure as possible, and we view the security of the apps you develop as a shared responsibility. As part of this, we provide some of that security control to you so you have the flexibility to meet your organization’s business requirements.

Salesforce security features enable you to empower your users to do their jobs safely and efficiently. This module covers two important ways to ensure the security of your Salesforce org when developing and running custom apps. Let’s start with Health Check.

“”

What Is Health Check?

Health Check is a dashboard that lets you see how closely the security settings in your org align with the settings recommended by Salesforce. It displays a score of 0–100, with 100 being the most secure setting configuration. From this single-page dashboard, you can adjust the robustness of the security mechanisms built into your org and fix vulnerable settings in just one click. All your security settings are available from a single page, making it easy to get a quick glance of your org’s overall security. A summary score shows how well your org is aligned with the Salesforce recommended, or baseline, standard.

Why Use Health Check?

Health Check can expose inactive or incorrectly configured security mechanisms in your org’s security settings, and you can use that information to improve your org’s security as you deploy custom apps. It’s important to use this built-in feature because any time you build and deploy a custom app, you impact the security of your org as a whole.

Most applications built on the Salesforce Platform are deployed to the owner’s org. This means that how your custom code runs depends on how you configure the security settings in your org.

Securing Salesforce Applications

Enabling the correct security permissions is key to ensuring your apps operate safely when deployed to Salesforce. You can build Lightning components using two programming models: Lightning Web Components (LWC) and the original model, Aura Components. However, in general, Salesforce is moving away from using Aura components, and we strongly encourage the use of LWC instead.

LWC are custom HTML elements built using HTML and JavaScript. LWC and Aura components can coexist and interoperate on a page. To admins and end users, they both appear as Lightning components. LWC uses core web components standards and provides only what’s necessary to perform well in Salesforce-supported browsers. Because LWC is built on code that runs natively in browsers, LWC is lightweight and delivers exceptional performance. Most of the code you write is standard JavaScript and HTML.

Note

Since LWC is becoming the standard for web app development, this module covers LWC security settings and conditions.

Secure Your LWC Session Settings

To run a Salesforce-powered app, you usually have all of these:

  1. A Salesforce org
  2. Browser-side code in LWC
  3. Server-side code in Apex

By enabling the correct security permissions, you can change how your apps operate when deployed to Salesforce. To access security permissions, go to Setup | Security or Setup and use the search box to find the exact setting you’re looking for. Most security settings are simple on/off toggles. We recommend enabling these security settings:

  • HttpOnly
  • User Certification
  • Cickjack Protection
  • HTTPS
  • Session Timeout
  • Cross-Site Scripting (XSS) Protection

Require HttpOnly Attribute

Setting the HttpOnly attribute changes how an app communicates with the Salesforce server by increasing the security of each cookie the app sends. Since HttpOnly prevents cookies from being read by JavaScript, the browser can receive the cookie, but it cannot be accessed or modified by a script running in the browser.

HttpOnly is an additional flag included in the Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of a client-side script accessing the protected cookie.

Enable User Certificates

Use this setting to allow certificate-based authentication to use PEM-encoded X.509 digital certificates to authenticate individual users to your org.

Enable Clickjack Protection

You can set the clickjack protection for a site to one of these levels.

  • Allow framing by any page (no protection).
  • Allow framing by the same origin only (recommended).
  • Don’t allow framing by any page (most protection).

Salesforce Communities have two clickjack protection parts. We recommend that you set both to the same level.

  • Force.com Communities site (set from the Force.com site detail page)
  • Site.com Communities site (set from the Site.com configuration page)

Require HTTPS

This setting must be enabled in two locations.

  • Enable HSTS for Sites and Communities in Session Settings.
  • Enable Require Secure Connections (HTTPS) in the community or Salesforce site security settings.

Set Session Timeout

It’s a good idea to set a short timeout period if your org has sensitive information and you want to enforce strong security.

You can set values, including:

  • Timeout value
  • Force logout on session timeout
  • Disable timeout warning popup

Enable Cross-Site Scripting (XSS) Protection

Enable the XSS protection setting to protect against reflected cross-site scripting attacks. If a reflected cross-site scripting attack is detected, the browser shows a blank page with no content. If there is no content, scripts cannot be used to inject attacks.

Now you know how to secure your org with LWC’s built-in features. In the next unit, explore how Shield helps you protect your apps.

Resources

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback