Secure

Because Apex generally runs in system context, permissions, field-level security, and sharing rules aren't taken into account during code execution. This might put applications at risk of inadvertently exposing sensitive data.

CRUD and FLS are authorisation settings that let Admins specify which objects and which fields on an object a user can access and modify. There are cases where developers use Visualforce or Lightning to display data derived from an SObject field in an indirect or processed form. In such scenarios CRUD and FLS should be manually enforced.

As a best practice, flows should be restricted to specific users. Omitting restrictions gives all users the possibility to invoke a flow, which is typically undesirable.

Cross-site scripting (XSS) attacks cover a broad range of attacks where malicious HTML or client-side scripting is provided to a Web application. The Web application includes malicious scripting in a response to a user of the Web application.

Sensitive information such as tokens, secrets and passwords should never be stored in the database.

Profiles define how users access objects and data and what they can do within the application. Granting "ViewAllData" or "ViewAllRecords" permissions at the profile level overrides any other record-level access mechanism and may give users excessive data access privileges.

SOQL/SOSL injection is a serious security vulnerability that results from the insecure construction of a database query, with user-supplied data. When queries are built unsafely from user input, instead of using type-safe bind parameters, malicious input may be used to change the structure of the query and bypass or change the application logic.

Insecure direct object references (IDORs) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorisation and access restricted resources.

Sensitive information should never be included in logs. While logging all information may be helpful during development, it's important to make sure that any sensitive user data and system information are not accidentally exposed. Debug logs should not contain any sensitive data such as usernames, passwords, contact information, PII, etc.).

Open redirect is a vulnerability that occurs when an application can redirect the users to a URL contained within untrusted input. By modifying the untrusted input to a malicious site, an attacker may launch a phishing scam and steal user credentials.

Requesting resources using the insecure HTTP protocol weakens the security of the entire page, as these requests are vulnerable to man-in-the-middle attacks, where an attacker eavesdrops on a network connection and views or modifies the communication between two parties.

Using open source components with well-known vulnerabilities is now a part of the OWASP Top 10. Insecure libraries can pose a considerable risk for your application. While some known vulnerabilities lead to only minor impacts, some of the most significant breaches to date have relied on exploiting known vulnerabilities in components.

Enforcing HTTPS is an essential step to protecting your application and users from attacks. Using non-secure endpoints in your integrations exposes your application and users to significant security risks.

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a vulnerability that enables attackers to send unauthorised commands that exploit a user's session. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Lightning Locker is the built-in security architecture for Lightning components. It enhances security by promoting several best practices, including eliminating access to specific APIs and framework internals. Lightning Locker can be disabled for an Aura component by setting the Salesforce API version to 39.0 or lower for the component. If an element is set to at least API version 40.0, Lightning Locker is enabled.

Session IDs should be treated as secrets and handled with care, as they may allow access to the Salesforce API on behalf of the running user.

Data placed in the localStorage persists after a session is closed, and thus, any actor with access to the browser will be able to obtain it. Furthermore, data in the localStorage or in the sessionStorage is visible to scripts that are running on the browser, and these scripts could belong to malicious third parties. Therefore, no sensitive or session information should be stored in the client-side storage.

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they intended to click on the top-level page. Thus, the attacker is "hijacking" clicks meant for a page and routing them to another page.

A recurring problem when developing applications is that people may accidentally hardcode and commit secrets to their remote Git repositories. Secrets include keys, passwords, API tokens, and other sensitive information. Secrets exposed in this way must be treated as compromised and be replaced, which can be costly.

As a best practice, the creation of a user's password should be managed by the platform. Setting a password programmatically increases security risk and, in most circumstances, isn't required.

In Apex, developers can use the System.Crypto class to implement various encryption algorithm, however some algorithms such as SHA1, MD5 are no longer considered secure by today's standards.

Handling sensitive fields in the UI requires extra caution and should be planned carefully.

The <isSecure> attribute controls whether a cookie can only be accessed through HTTPS or not. By setting this attribute to false, sensitive cookies may be exposed if sent over an insecure connection.

With Winter '24, to prevent unauthorized serialization and deserialization across packaging namespaces, Salesforce will validate the JsonAccess annotation of your Apex classes. This validation protects your Apex classes from unauthorized serialization and deserialization across packaging namespaces.

The user browser can save and remember the entered values for user input fields with autocomplete-enabled attributes. This might reveal sensitive information like passwords, especially on public and multi-user computers.

When using "not equal" conditions, a sharing rule operates on an opt-out basis, meaning that the sharing occurs unless certain non-sharing conditions are met. As a best practice, especially when sharing CRM data with external users, one should define the sharing rules on an 'opt-in' basis. This approach keeps data private by default and opens up visibility exclusively when specific conditions apply.

HTTP Referer headers can be modified by attackers. Making a decision based on the value of the referer can be dangerous.

Subresource Integrity (SRI) is a security feature that enables browsers to verify that the resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.

Some JavaScript operations, such as eval and other reflection operations, introduce a significant security risk. For this reason, they are blocked by the Lightning Locker and are generally discouraged.