The goal of this security article is to empower developers and architects to design, build and maintain secure systems that protect the data and assets of their users and organizations. Working as a Salesforce Security Specialist within Deloitte has taught me to adopt the Zero trust model (Never trust, always verify)! Performing security audits on consulting projects gave me a clear insight about Security from an Architect’s & Developer’s perspective. Let’s have a look at both of the perspectives!

Cloud Security from an Architect’s perspective

As an architect, are you wondering how an ideal cloud security implementation looks like?

Those crushing it in this field have done exceedingly well in the below 6 cloud security topics:

• Data Protection
• Identity & Access management
• Governance
• Visibility & Monitoring
• Threat Detection & Response
• Audit & Compliance

How does this translate to Salesforce Security?

Normally Data Protection and IAM (Identity & Access Management) also appear in the implementation phase, but the other 4 topics only come to light after a production release. Hence it is very important to think about these topics well in advance during the design / architectural phase.

Security from a Developer’s perspective

I consider the OWASP Top 10 as the holy grail for developers wanting to build and maintain a secure application. OWASP Top 10 2021 is the latest version which highlights the most prevalent vulnerabilities in today’s world.

A01 Broken Access Control: Opening up protected actions to unauthenticated/unauthorized users

• Implement controllers ‘with sharing’ explicitly
• Check CRUD FLS when running SOQL query in apex
• Perform access checks for any data coming from the front end. Even though the front end has robust frameworks, never trust any data that enters the server side logic. For example, consider view and update screens. Always make sure on the backend that a user hasn’t tampered with the data when doing an update call
• In the front end, perform origin checks in event listeners. Any postMessage calls from a different window shouldn’t be blindly trusted
• Never expose more than what is needed. For example, for an updateContactPhone operation, do not expect a Contact record in the request. Instead accept an updated phone number

A02 Cryptographic Failures: Hardcoded passwords, plaintext secrets and PII data, weak cipher

• Store integration passwords strictly in named credentials
• Encrypt secrets like credit card numbers / bank account numbers using encrypted fields or Shield platform encryption
• Stop using MD5 and SHA1 cryptographic hash functions

A03 Injection: Unescaped data executed as scripts on the frontend. Dynamic queries leaking unwanted data to the caller

• Use static queries / bind variables. If dynamic query is necessary then use escapeSinglequotes to sanitize inputs
• Output encoding, avoid unescaping values
• Avoid using lwc:dom=”manual”, let LWC handle DOM manipulations

A04 Insecure design: Insecure design patterns and lack of governance. This is directly related to what is mentioned in the previous section. If the cloud security for architects are followed strictly then this is already mitigated. Here are some pointers:

• Avoid using client_credentials / username password flow. Prefer the OAuth Auth code with PKCE for integrations
• Unless legacy is involved, go for OpenID connect for SSO instead of SAML
• Have SSO and MFA setup via a trusted IdP
• Maintain a design decision document indicating the allowed integration patterns
• Salesforce inherently does not provide rate limiting and DDoS protection, in case of external communities, always implement a WAF to safeguard against DDoS attacks
• Invest in a middleware / api-gateway

A05 Security Misconfiguration: This mostly refers to mistakes in configuration leading to security incidents

• For integration user, enable the API only permission so that UI access is blocked
• Make sure API Enabled is not turned on for unwanted profiles / permission sets
• Close down sharing on the org-default sharing
• Practice the principle of least privilege

A06 Vulnerable and Outdated Components: Outdated components in any system struggle with Common Vulnerability and Exposures (CVEs)

• Upgrade versions regularly to get security patches on time! (browser / dataloader / API versions / CLI version / installed package versions)
• Setup automatic monitoring to find vulnerabilities
• Subscribe to security updates!

A07 Identification and Authentication Failures: Brute force, credential stuffing and other automated attack attempts on Identity if successful can leave the organization red-faced and helpless

• Go for real time event monitoring subscription
• Build enhanced transaction security policies for events like CredentialStuffing, APIAnomaly, ReportAnomaly, LoginEvent etc
• Having MFA and SSO definitely helps. This shifts the login event issues to the IdP

A08 Software and Data Integrity Failures: Security issues in components used by the CICD release pipelines lead to incorrect code being deployed to the target environment. Broken access control can lead to data integrity issues

• CICD pipelines should know the source from where the code originates
• Perform an integrity check after JSON deserialization on the external data before committing to the database
• Perform an integrity check after JSON serialization before doing a callout to avoid sending wrong data to untrusted sources

A09 Security Logging and Monitoring Failures: This absence of logging and monitoring on security events like LoginEvents, CredentialStuffing can lead to drastic consequences. The mitigation for this is largely covered in A07 Identification and Authentication Failures

• Implement log drains (logging solution outside the platform). This will enable threat detection & response across organization. One example would be having an application like Splunk aggregate logs from all the systems

A10 Server Side Request Forgery (SSRF): This is about storing unvalidated data to the backend database. Unlike CSRF which forces a user to navigate to an insecure website/location, SSRF is mainly done to steal data from the backend database. The A01 Broken Access Control & A03 Injection highlights the mitigations for this

General recommendations for projects

• Version management is a must for any project. Follow strict manual pull request review process before merging code. Review like an auditor, not like a policeman!
• Create an environment of trust within the project to allow colleagues, both junior and senior, report security issues without fear
• As part of governance, create a guideline on determining the severity of a security issue and the corresponding resolution time. For example, high severity issues should be fixed within 24 hours etc
• Invest in an independent software review and penetration testing exercise on a periodic basis. Be sure to checkout the information in the Salesforce Security Assessment portal before planning a penetration test for your full copy Salesforce sandbox

Conclusion

The threat profile 10 years ago was completely different than what it is now. The vulnerability landscape is an evolving one!

In the end, the golden question still is, when can a system be declared secure? And the answer is NEVER. It is all about following the security incident trends & mitigating risks. Following the above recommendations will definitely help in designing and maintaining a secure system.