Salesforce Security Best Practices and Tips

If you are contemplating developing a customized solution that runs on Salesforce but don’t know if it’s secure enough, this article is for you. 

 

A part of the article is dedicated to the Salesforce security model best practices. If you already have a Salesforce solution, you may still find it helpful: administrators and developers can adjust some settings better, use extra tools, and learn new tricks to enhance data security in Salesforce systems. Onix is here to help too!

 

Only in August 2022, IT Governance alone identified 112 security incidents that resulted in 97M compromised records. The number of data breaches continues to grow yearly as more businesses go online, more employees work remotely, and bad guys become more inventive.

 

Companies failing to implement sufficient cybersecurity protocols and safeguards risk facing severe consequences, such as revenue loss, non-compliance fines, legal fees, and loss of trust.

 

Salesforce, one of the biggest and most popular CRM platforms, stores not only gigabytes of customer data but also its customers’ vital prospect lists, pricing and discounting details, sales pipelines, and often sensitive information.

 

Understanding the potentially fatal impact of a successful Salesforce cyber-attack or careless actions by internal players, the SaaS provider takes great pains to keep its platform secure.

Read on to learn what Salesforce security best practices make it one of the safest CRM solutions and how admins and developers can ensure maximum data security. But let’s start with an overview of risks and threats specific to the CRM platform.

 

Salesforce Security Breach Risks

Unfortunately, some Salesforce security vulnerabilities are rooted in the platform’s advantages. 

 

For example:  

 

• Easy integration with multiple services via APIs

Not every third-party app you connect to Salesforce may be as safe as Salesforce itself. Integrated apps can potentially create unsecured doors into your instance and introduce new security risks. APIs can make your Salesforce org vulnerable to:

 

• DDoS attacks
• code injections
• fraudulent logins
• unsecured cardholder information
• replay attacks
• exposed data in URI keys

 

If a connected app is compromised, it could expose your internal Salesforce data. Granting access to a shady or unsecured API may lead to hacks, data breaches, and compliance issues.

 

• Empowered users

Virtually any Salesforce user can be a lesser or greater insider threat based on their level of access to information housed on the cloud platform and ability to make changes. 

 

For example, employees may share or extract sensitive data inadvertently or intentionally. An enabled "export" permission makes it easy for unscrupulous employees to steal information like leads or customer lists.

 

More and more CRM users that work remotely access Salesforce on personal devices, creating additional risks. 

 

Common insider threats to Salesforce data include:

 

• departing employees who may take valuable or sensitive information with them
• insiders who want to harm a company’s reputation by leaking data
• negligent insiders whose errors can expose a company to security threats
• privileged users that enjoy more access rights than their duties require and can make configuration changes affecting data security
• unauthorized persons obtaining a user’s credentials and other account information

 

• Salesforce being configurable, customizable, and open

Misconfiguration is one of the biggest risks to cloud environments. Salesforce org security is often neglected in favor of configuration changes. Countless permission possibilities make it easy to leave valuable data exposed. Teams that don’t know the ropes of the many Salesforce configurations risk missing critical gaps.

 

Contractors are among external users that are granted access to SF. According to the 2021 SaaS Risk Report by Varonis, 75% of contractor identities remain active after they leave.

 

Salesforce opening its functionality for developers and social communities also opens up possibilities for security incidents. 

 

Outsider attacks are a persistent threat too. For example, one Salesforce data breach affected over 200,000 customers of Hanna Andersson, a children’s clothing company. Salesforce handled the customers’ personal and payment information when they engaged in a sale.

 

From September 16 through November 11, 2019, the Salesforce network suffered a malware infiltration. Hackers were able to scrape consumer data, including credit card information and personal identifiers, from about 10,000 consumers. The hackers sold the data on the dark web and retained access to the database for several months before law enforcement found it out.

   

In 2020, a California resident filed a federal class action lawsuit against Salesforce and Hanna Andersson for negligence, declaratory relief, and violations under the California Unfair Competition Law.

 

The complaint claimed that both companies failed to protect private data, failed to detect the data breach, employed inadequate security practices, and did not warn consumers about their deficient practices.

 

In 2021, Salesforce and Hanna Andersson agreed to pay $400,000 to resolve the lawsuit and offered identity theft protection services to the affected customers. Salesforce focused heavily on integrating monitoring systems to catch breaches early on.

 

Handling situations like these over two decades, Salesforce has amassed a vast knowledge of bad practices. Salesforce Trust provides a transparent and real-time view of its security measures and updates on attacks that can affect its customers. The company has also developed a robust data security model and a comprehensive set of controls to secure each Salesforce org. 

 

The following chapter provides an overview of key best practices for Salesforce cybersecurity.

 

 

Primary Salesforce Data Security Best Practices

The primary cybersecurity best practices implemented by Salesforce include:

 

1. Multi-factor authentication (MFA)

Salesforce requires all customers to use MFA when accessing Salesforce products. Users must confirm their identity with an authentication app on a mobile phone or a security key.

 

MFA makes phishing attacks useless: if the bad guys obtain a user’s credentials, they will not be able to use them without the user’s smartphone, for example.

 

2. Authentication data security

Every time a user enters their username and password, the platform creates a session cookie for them. Instead of storing the credentials data in it, Salesforce uses encoded session IDs.

 

If somebody intercepts cookies from a user’s browser, they won’t be able to access the user’s authentication data. The default session timeout, two hours of inactivity, also contributes to security.

 

3. Event monitoring

An automatic system within Salesforce promptly notifies customers of potentially dangerous actions of its users, such as weak passwords or insecure settings, and suspicious processes involving their data.

 

The change logging feature can track multiple event types and allows admins to view, filter, and download event logs through the Event Log File Browser. If something goes wrong, the platform will alarm both the customer and Salesforce cybersecurity personnel to fix the problem.

 

4. A comprehensive and flexible data-sharing model

Salesforce customers typically have dozens or hundreds of employees with different responsibilities. The multi-layered data security model in Salesforce enables administrators and app developers to manage these employees’ access to information from an org perspective down to an individual record.

 

This means not only a better user experience but also error reduction and greater safety: if a user’s account is compromised, intruders won’t go further than information open to that user.

 

The three key constructs related to data in Salesforce include:

 

1. Objects similar to tables in databases, such as Projects, Accounts, Portfolios, Resources, Files, Tasks, Reports, etc.
2. Fields correlating with a table's columns, e.g., Project name, Description, Status, Start date, Finish date, etc.
3. Records that correspond to rows of data inside a table.

 

Salesforce secures access to these data sets on three levels:

 

Layer 1: Object-level security

Two configurations help manage object-level access: Profiles and Permission Sets. Each user is assigned a profile, where the admin (the person with principal administrative rights in the organization) allows minimum access to data needed for a particular job role and configures things like login IP restrictions. Admin can grant further access and abilities to the user through multiple permission sets.

 

For example, the admin may allow a salesperson to see only a specific object they work with, while their manager will have the right to view all objects and create new ones. The admin can issue and take away these permissions from users at any level at any time. 

 

Layer 2: Field-level security

Profiles and permission sets also control field-level access. Admins can provide read and write permissions for individual fields within an object. When an admin hides a field from a user, it means the user will not be able to access it. A field hidden with field-level security will not be accessible through any entry points, including APIs.

 

Layer 3: Record-level security, aka Salesforce sharing model or record sharing

There are five ways for users to share records and access other users’ records. After configuring org-wide defaults to lock down their data, they can use other record-level security tools to open records to selected users as needed.

The record-level security tools include:

 

1) Organization-wide sharing defaults (OWD). Every record has a field called “OwnerId” that refers to a real user, usually the person who created the record and has full create, read, update, and delete access to it. OWD control the default behavior of users regarding access to a record they don’t own. OWD must be either public read-only or private to create sharing rules.

 

2) Role hierarchies. Different job roles have different record access requirements. Users with a higher role usually need and can access records to which users in lower roles have access. To use this upward sharing rule, an administrator has to add a user to a higher role and then grant access.

 

3) Sharing rules. If users need to share records they own laterally, e.g., with their teammates, sharing rules apply that extend sharing access to groups, roles, or individuals.

 

They enable record sharing laterally and in an ad-hoc fashion via public groups:

 

a) Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public group ownership. These rules allow for exceptions to OWD and the role hierarchy that give a user access to records they don’t hold. Owner-based sharing rules are limited to 300 per organization.

 

b) Criteria-based sharing rules open access to a record based on the value of a field in it, irrespective of who owns the record. If one or multiple criteria are met, records are shared with an eligible individual or group. An organization can have up to 50 such rules.

 

c)Guest user sharing rule that grants access to records to an unauthenticated user using sharing settings is seldom used because it is not recommended to expose data to such users. 

 

4) Manual sharing. If a record’s OWD is private or public read-only, end-users can share it with others manually. This permission is available through the Sharing button on the record details page. If the ownership of a shared record changes, all users whom the original owner had granted access will lose it. 

 

5) Apex managed sharing. In cases when records can’t be shared via UI or settings, developers can write Apex code to do so programmatically. It can be used only when a record’s OWD is set as private or public read-only.

 

5. Data encryption

Two types of encryption are available — for standard and premium subscriptions — allowing to encrypt most data stored on the platform. Salesforce provides encryption whenever data travels to and from the platform. The encrypted connection prevents Salesforce data from being exposed when you export it.

 

6. Data storage and backup

Salesforce stores user data using multiple active clusters. The database is hosted on carrier-class storage that may need only a few minutes of downtime per year. If one data center goes offline or a server breaks, all data will still be accessible. Moreover, data can be backed up weekly or monthly for greater security.

The best practices for Salesforce security are not implemented only on the CRM’s side. Customers need to keep the shared responsibility in mind: Salesforce secures the cloud platform, but once a company inputs its data, it’s up to them to protect it with an extra layer of security beyond what Salesforce provides.

 

Administrators can activate and adjust many tools, settings, and parameters to make their instances more secure. Here are Salesforce security tips to help minimize external threats and breaches caused by employee error or malicious intent. 

 

If we were to rank the methods, our first advice would be: start with your Salesforce Health Check.

 

How to Run a Security Health Check for Salesforce Instances

The Salesforce Security Health Check tool lets administrators thoroughly assess their instance’s well-being by scanning the settings that ensure its safety. Having identified possible risks and vulnerabilities, the admin can fix the issues and even improve their instance’s security with one click, all from one page.

 

You can start Health Check by searching for it in the Quick Find box of your Setup page or heading over to Security > Health Check.

 

Next, in the Baseline dropdown, choose the Salesforce Baseline Standard or a custom Baseline. This means you can run the check either against the settings for different risk levels recommended by Salesforce or against a customized Baseline.

 

In the latter case, Security Health Check allows adding up to five custom Baselines to make the check as rigorous as needed or make the settings less restrictive than the Baseline selected.

 

For example, if your healthcare organization handles sensitive data and Personally Identifiable Information, you can add a custom Baseline about GDPR standards.

 

You can create a custom Baseline as follows:

 

1. Click on “Export Baseline” in the Baseline Controls Menu.

 

2. Use a text editor to edit the exported XML file. When making adjustments in the risk categories, make sure not to add or delete risk categories, names, and even quotation marks: it would lead to import failure.

 

Some specific setting values cannot be modified, and moving a security setting to the Informational category means removing it from the Health Check score calculation.

 

3. Click on “Import Baseline” in the Baseline Controls Menu to save and import the XML file. 

 

4. Enter your custom Baseline’s name in the dialog box that opens.

 

5. Assign your custom Baseline a unique API name without any spaces or special characters.

 

6. Set the new custom Baseline as the default Baseline for your Salesforce security review, if you want. It will appear in the dropdown once the import is completed.

 

So, after you click on the Baseline dropdown and select the desired Baseline, Security Health Check would run the scan, produce a health score, and give recommendations on addressing weaknesses.

 

The tool uses a proprietary formula to assess the compliance of your instance’s security settings with Salesforce Baseline Standard or a customized Baseline. Your org’s health can be scored through the following percentages:

 

• ≦ 54% — very poor
• 55%-59% —  poor
• 70%-79% — good
• 80%-89% — very good
• 90%-100% — excellent

 

The more restrictive your settings, the higher the score will be.

Security Health Check divides any discovered vulnerabilities into four classes: high-risk, medium-risk, low-risk, and Informational Security Settings. Within each section, settings to review will also be categorized as “Critical,” “Warning,” and “Compliant.” This will give you a prioritized checklist of items to review and fix.

 

For example, Salesforce Baseline Standard limits invalid login attempts to three. If your instance’s settings allow more, Health Check will flag a high-risk vulnerability, advise you to mitigate the risk, and create a shortcut for the necessary modification.

 

Other settings Health Check might flag include:

 

• minimum password complexity
• forced logouts on session timeouts
• forced re-logins after an administrator logs in as another user
• clickjack protection
• locking sessions to the IP address from which they originated

 

The types of recommendations include:

 

• Password Policies
• Session Settings
• Network Access

 

Click on “Fix Risks” to start adjusting your settings.

Occasionally, you wouldn’t want to adjust your settings to match Salesforce’s recommendations. For example, Salesforce recommends disabling the option to log in as another user. However, if you often do it when troubleshooting issues, you would want it enabled.

 

Just like humans periodically undergo health checkups even when there are no perceptible risks, admins should undertake a security health check for Salesforce instances on a regular schedule, e.g., monthly or quarterly.

 

Salesforce regularly updates its Baseline Standard to adapt to new threats and changes in best practices, and the platform itself is updated three times per year. Industry standards also change, and so do your organization’s security requirements.

 

20 More Tips for Greater Data Security in Salesforce Organizations

 

1. Identify your Salesforce security responsibilities, vulnerabilities, and misconfigurations

Understanding what data you have in the CRM system and identifying misconfigurations are essential to strengthening your org’s security. It’s also crucial to understand which security tasks are handled by Salesforce and which are your security team’s responsibility. 

 

It may help to review your internal processes to see if you can adjust a process to meet Salesforce standards instead of overly customizing the CRM platform to fit your processes.

 

For example, Onix specialists can help you identify and fix misconfigurations, incorrect permissions, data exposures in your Salesforce environment, and other potential issues with Salesforce data security.

 

 

Suppose you feel that the Salesforce Security Health Check is insufficient for your needs and that your company’s security policy requires more robust customizable capabilities.

 

In that case, you may reinforce your security strategy with third-party solutions. For example, OwnBackup Secure allows automation of the remediation of identified misconfigurations with detailed action plans and real-time alerts.

 

2. Be super-cautious with permissions

Sometimes, admins initially provide users with broad access to objects and fields and later try to hide some data by limiting fields’ visibility for individual profiles.

 

However, hiding a field does not cancel a user’s underlying access. They may still access the information by creating a report or through a data export. Integrated apps may also view info within hidden fields.

 

The recommended approach is to control access by granting permissions to objects and fields to specific profiles or users. Follow the principle of least privilege: users, including APIs, should have access only to the bare minimum of information necessary to do their job.

 

Allow users the least privilege level and selectively grant higher privileges as needed on a case-to-case basis. Refrain from using the permissions to “view all” or “modify all” within profiles. Be extra careful with “export” permissions. 

 

Keep the number of ownership-based sharing rules to 100 per object and the number of criteria-sharing rules to 50 per object.

 

Ensure that your Salesforce security team can audit privileged users and is notified when changes are made. 

 

Don’t forget about external users. Any org that runs a community should review its external sharing and security model, including that of guest users, and take extra care to lockdown records, objects, and permissions.

 

Audit your configuration and check whether authenticated and unauthenticated community users can access only what you want them to. If possible, enforce authenticated access on your communities.

 

Admins should review and revalidate permissions over time, including inactive accounts. For example, they must properly offboard contractors once the cooperation is over.

 

3. Install apps for specific profiles

When installing an app or package, you can select to “Install for Admins Only,” “Install for Specific Profiles,” or “Install for All Users” (i.e. opening access to Salesforce for partners, vendors, contractors, and everyone else in your Salesforce environment).

 

Once access is granted, you would have to remove users’ permissions manually when needed. The more secure approach is to install the app only for specific profiles with the default “no access” for all users and then add additional profiles and users whenever necessary.

 

4. Secure data within packages during installation

When installing packages, users can select from several settings: “Managed” or “Unmanaged,” and “Public” or “Protected.”

 

The “Managed” option allows creating a unique “Custom Namespace” for your package to store any components, Visualforce pages, classes, or credentials belonging to the package. The “Unmanaged” setting keeps those items in the default or local Namespace.

 

The “Public” setting provides access to the data within the package to any user. The “Protected” setting limits access to the users and components within the Namespace.

 

The optimal method is to set the package to “Managed” and “Protected.”

 

5. Secure your APIs

Before giving access to any API you connect to Salesforce, look into its security model. This applies to any third-party integrations, such as marketing automation, computer telephony integrations, data enrichment tools, and even your own custom API work. 

 

Treat any API that accesses your Salesforce instance like any other user. The admin must be able to control what it can and can’t do. You may create a dedicated integration user — a Salesforce license not used by any human but intended solely for that API with its own profile and permission sets.

 

Then you can enable permissions for specific roles and enforce them as “API only,” ensuring the integration can’t access your instance in any other way and view or modify data it shouldn’t.

 

Assign them only “read” access, unless otherwise is necessary, and enforce the same password-level policies and location-specific restrictions as for other roles in your Salesforce org.

 

It makes sense to require more robust passwords for integration users: at least 20 random characters, including upper- and lowercase letters, digits, and special symbols.

 

You can also restrict the API’s access to your Salesforce instance so that it can log in only from its own partner or vendor’s servers. 

 

When configuring integrations, developers often use unencrypted HTTP for testing and troubleshooting. When insecure HTTP is not disabled, sensitive information can be exposed to outsiders.

 

Other parties may read and store records within the unencrypted API calls, including login credentials or an OAuth token. None of your integrations should have “Disable Protocol Security” selected. You can configure this setting under Setup > Remote Site Settings > select Details for a specific endpoint.

 

You also need to log the integration users’ behavior, conduct regular audits, review them periodically, and revoke access to dormant apps.

 

6. Enable App Allowlisting

Users may also create vulnerabilities by giving solutions access to SF. Suppose an employee allows a messenger access to Salesforce to receive notifications about Opportunities, unaware that this violates the organization’s GDPR or HIPAA compliance. It could take days to months to spot this issue and fix it.

 

Enable App Allowlisting in the org to prevent such situations. It lets admins specify to which apps users can and cannot grant access. They can manage user authorization at the org-wide level (all users) or for specific users and apply the same limitations to new users.

 

 

To enable App Allowlisting in your org, the admin must submit a case or call Salesforce. After it has enabled the feature, the admin can assign specific profiles and permission sets access to specific apps:

 

1. Under “Manage Connected Apps,” click “Edit” next to the app in question.
2. Next, under OAuth policies > Permitted Users, select “Admin-approved users are pre-authorized.”
3. Under “Manage Connected Apps,” if they click on the app’s label to bring up the Connected App Detail, the admin may assign Profiles and Permission Sets to access the app.

 

7. Use Salesforce Shield

Suppose you need to go beyond the standard security measures provided by Salesforce and bolster your business-critical app. It’s especially relevant in the financial and healthcare domains, with additional layers of security to comply with privacy policy, regulatory requirements, and contractual obligations. In that case, you may strengthen organization-level access with Salesforce Shield. 

 

The instrument includes three main features:

 

• Shield platform encryption

With Shield, admins and developers can encrypt fields in standard and custom objects and unstructured content, such as files of any size, using an advanced HSM-based key derivation system. Shield’s encryption supports search, validation rules, and workflows without intervening with the functionalities.

 

• Event monitoring

Shield brings richer functionality to event monitoring for large companies or those needing more complex auditing. Shield’s event monitoring gives a more granular overview of user behavior and app performance. Admins can see the history of all their user logins, including the login methods used, and see all interactions, including who is accessing what, where, and when. 

 

• Field Audit Trail

Field Audit Trail helps realize stringent audit requirements for a Salesforce org by tracking standard and custom objects. Admins can see the state and value of data going back up to 10 years across objects, accounts, cases, contacts, leads, and opportunities.

 

They can select specific fields for field history tracking that will record the date, time, and who made the change to a particular field. Retaining archived history data helps organizations comply with industry regulations related to audit capability and data retention. Admins can also set triggers to receive notifications when somebody deletes specific data.

 

Salesforce Shield also allows many Salesforce security policies to be automated.

 

8. Perform regular backups

Regular backups are necessary for protecting critical data and metadata and a quick and hassle-free recovery, should your data be compromised. 

 

For example, automated daily backups will ensure that employees can resume work with the most current data quickly after an incident.

 

Salesforce’s Enterprise, Performance, and Unlimited editions limit backups to once per week. This may be insufficient for some businesses. A third-party backup and recovery solution, such as Coupler.io, elastic.io, or SpinOne, may provide real-time incident alerts, pinpoint compromised data, and help restore your system after an incident.

 

9. Invest in change monitoring tools

It’s essential to track what users are doing with data and receive alerts if their actions are potentially harmful. When Salesforce environments are modified, it’s also important to consider how these changes are documented and verified. It may be reasonable to invest in tools that can manage and monitor all users accessing data and all modifications to avoid misconfiguration.

 

For example, DatAdvantage Cloud monitors access and activity, issues alarms on suspicious behavior, and identifies security posture issues or misconfigurations.

 

SpinOne allows versioning to recover from previous snapshots and full reversion of your multiple Salesforce environments into earlier versions for data and metadata in several clicks. AppOmni can help you review the level of access of all your users from a single page.

 

10. Implement password best practices

Salesforce’s default minimum for passwords is 8 symbols, but security experts now recommend at least 15. Salesforce offers six levels of complexity to choose from.

 

Salesforce does not prevent users from adding their actual password to their security question, so make sure to enable the Cannot Contain Password setting. Also, disable caching and autocomplete on your Salesforce login page.

 

The default password expiration setting is 90 days. If you opt for a shorter period, you need to turn on Salesforce’s Enforce password history setting to prevent users from reusing passwords.

 

11. Set trusted IP ranges

Admins can allow users to access their org instance only from the corporate network or VPN and prevent access from specific IP ranges.

 

A trusted IP range includes safe or familiar IP addresses from which Salesforce users can log in. A company’s trusted IP range usually includes office locations and other private networks that employees normally access. 

To configure the trusted IP range feature, find Network Access in Setup and click on “New” to create a new trusted IP range. In case of multiple trusted IP ranges, add informative descriptions to specify which range applies to which use case.

 

Once a trusted IP range is set up, users who access Salesforce outside of that range are required to verify their identity. Login will require a security token — an alphanumeric key often used in conjunction with a user’s password. 

 

For example, to access Salesforce via API, they need to append their security token to the end of their password. With MFA enabled, they will need to enter the password and then their security token.

 

If it is unavailable, they must use the Salesforce authenticator app to generate a new one and send it to their email box. If a user uses a device outside your IP range, they will not be able to reset their security token.

 

Admins can also define hours for usage and session-specific settings for logged-in users.

 

12. Enable custom login flows

Authorized users occasionally may need to access your instance under unusual conditions, but it shouldn’t create security risks for your business. Use custom login flows to put additional authentication steps in place for login attempts that seem suspicious. 

 

For example, suppose a user tries to log in from a restricted IP or out of regular working hours. You can set a flow to be triggered that would ask the user a secret question, notify an admin so they can validate or reject the login attempt, or require other actions for extra security.

 

13. Track login history

Salesforce provides a standard feature for tracking login history called “New Login Location Report.” 

 

For example, suppose a salesperson is using an application like WorkBench, Browser, Data Loader, etc., to export leads. This could signal that they plan to quit and take leads and other confidential information with them.

 

14. Pay special attention to data encryption

Make sure to use platform encryption when a new tenant secret is generated. Also, make sure to destroy old encryption keys after data decryption.

 

15. Use Salesforce Sandbox 

Use Sandbox for safer and simpler verification of untested or untrustworthy code. In an isolated test environment that mirrors production environments, you can experiment with different variables and test system changes before they go live. This will help you remove threats before they become a problem and prevent potentially malicious code from infiltrating your system.

 

Some admins tend to delay installing security updates because they might impact the end-users’ experience. Testing these updates in Sandbox will help you deploy these changes more confidently and timely.

 

16. Stay updated

Make sure that all devices accessing Salesforce should have the latest version of the OS, browser, and anti-malware software.

 

As more users tend to work remotely, tightening Salesforce default user access settings and requirements may be reasonable.

 

17. Implement a virus scanner

Unsecured devices, communities, sites, attachment uploads, email-to-case, and other areas of entry create multiple Salesforce security vulnerabilities, whereas the platform doesn’t have a native virus scanner solution in place. A third-party virus scanner app, such as EZProtect and its alternatives, may provide extra security.

 

18. Turn on Clickjack protection

Hackers can use clickjacking, i.e. luring a user into clicking a malicious link or button, to access and modify Salesforce instance data. Salesforce safeguards standard pages against clickjacking, but it never hurts to enable clickjack protection in your Session Settings to enhance the protection of customer Visualforce pages and setup and non-setup Salesforce pages.

 

19. Implement Salesforce app development best practices

Salesforce security guide empowers app developers to secure the apps and improve the cybersecurity of customers’ databases on the platform. Some of the threats that require special attention are:

 

1) Cross-site scripting (XSS). XSS attacks occur when malicious HTML or client-side scripting is provided to a web application, enabling attackers to take control of a web app user’s session and execute malicious code. Some likely targets include bulletin boards or user comment-style websites, news, or email archives. Salesforce’s Visualforce developer guide provides guidelines to restrict such scenarios during app development.

 

2) Cross-site request forgery (CSRF). A cyber criminal’s web page contains an URL created with malicious intent. If a user logged into a valid web page visits the attacker's web page, the URL is retrieved to perform the actions planned by the attacker. Visualforce guidelines for CSRF can help developers safeguard their code in these scenarios.

 

3) SOQL Injection. Bad guys can modify unvalidated user input in queries in the Salesforce database query language for malicious purposes. To secure code against SOQL attacks, developers should implement the defense mechanisms explained in Visualforce guidelines for SOQL Injection.

 

20. Educate your employees 

Even the FBI lists employee education as a way for businesses to protect themselves from cyber-attacks. 

 

Ensure employees’ education on company policies regarding data usage, threats, and vulnerabilities. Share your organization’s Salesforce security rules and action plan with all employees and other users, if applicable, to ensure that everyone understands how to use Salesforce safely.

 

Employees must know how to spot a red flag, how to report abnormal activities within the organization, when they should inform managers, etc. Check when you last held employee training aimed at phishing prevention. Make sure the employees are updated regularly: remote employees often delay updating their software, devices, and best practices.

 

Final Words

Salesforce is a robust and secure CRM platform with mandatory MFA, advanced encryption, a comprehensive and flexible data sharing model, and a notification system.

 

However, it is up to each organization to evaluate its data management, put varied Salesforce security best practices in place, implement policies and technology that go above and beyond Salesforce’s innate security controls when needed, and continuously update and monitor security systems.

 

Unfortunately, IT and security teams are often overwhelmed with multiple competing priorities. That, combined with the complexity of Salesforce permission configurations, could jeopardize a company’s data, customers’ information, or other sensitive information, putting its business processes, reputation, and profitability at risk. 

 

We hope you found this article helpful and will be able to apply some Salesforce tips and best practices to increase the security of your company’s data. If you have questions, need a Salesforce security review, or want experienced developers to create a secure custom Salesforce application for you, please don’t hesitate to contact Onix!

 

Our company has been developing products that run on the Salesforce platform for six years, the services including:

 

• Application solution architecture
• Full-cycle Salesforce app development
• Salesforce migration
• Post-release maintenance
• Improving existing Salesforce applications
• Salesforce consulting