DeloitteEngineering Blog | Netherlands

Salesforce Cloud Security for People in a Hurry


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:

How does this translate to Salesforce Security?

6 main Cloud Security topics tailored for Salesforce

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

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

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

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:

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

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

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

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

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

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


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.