In our previous blog post, “One way to keep your org secure: Salesforce Health Check” we covered the built-in Salesforce Health Check tool, the benefits of running a health check, and why you and your company need one.
This blog will cover some in-depth steps you can follow as a guide if you are a Salesforce developer or Admin to make your org more secure. That being said, let’s get to it!
The Lightning Platform has been migrating from Aura components to Lightning Web Components (LWC) for some years. Even though both are still supported and can coexist on the same page and even share information, Salesforce is focusing on LWC, and we should do the same.
When you run your Health Check application, you have 3 moving parts involved:
- The Salesforce org
- The client (LWC)
- The backend code (Apex)
We have configurations available in Setup > Security, allowing us to configure how the app runs. I recommend turning on the following options:
- Require HttpOnly Attribute
Setting the HttpOnly attribute will change 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 modified 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
This setting allows 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.
- 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 the 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. Without content, scripts cannot be used to inject attacks.
- Use the Latest Version of Locker
Lightning Locker provides component isolation and security, allowing code from many sources to execute and interact using safe, standard APIs and event mechanisms. Lightning Locker is enabled for all custom LWCs and automatically updates. If you’re using Aura, check your version for compatibility.
One more thing...
I want to spend more time discussing a feature that helps us run our application even more securely. And I am talking about Salesforce Shield. Salesforce Shield allows you to run your application more securely with some features like encryption and monitoring. It adds an extra layer of confidence, privacy, and security and lets us build a new level of trust, compliance, transparency, and governance.
Salesforce Shields is composed of 3 easy to use point and clicks tools, which are:
- Platform Encryption: It is designed to bring us state-of-the-art encryption while we do not lose access to key features such as search, validation rules, etc. It can derive the encryption keys from org-specific data or even import our encryption keys(adding an extra layer of control)
- Monitoring Events: We often need to track specific events in our orgs (who accesses a piece of data, how the encryption keys are, who is logging, and from where). Monitoring events is the tool for it allowing us to track and access all these events and more from the API and integrate it with the monitoring tool of our choice(New Relic, Splunk, others)
- Audit Trail: Some industries require us to keep track of changes in data. Turning on tracking specific fields and setting up an audit policy, we can store historical values for up to 10 years.
Conclusion
It is essential to consider security while developing apps and maintaining our Salesforce org secure. And even though it might seem complicated (and it is), incorporating the Health Check tool and salesforce shield in our development process will help us to keep our org in a good, healthy state.
You can also watch our on-demand Health Check Assessment webinar by my colleagues Zach and Heather, where they covered 4 simple steps to ensure the health of your Salesforce org.
