🔐 The OWASP Top 10:2025 — But Make It Salesforce

💭 In every Salesforce project, there comes a moment…

The feature is complete. The tests pass. The deployment succeeds. The business signs off. Then someone from security asks:

"Does this Apex enforce sharing?" "Who can actually run this Flow?" "Why does this integration user have System Administrator permissions?" "What happens if this external package is compromised?"

Suddenly your working application becomes a security conversation.

And that's when many Salesforce developers discover an uncomfortable truth:

Salesforce is not secure by default. Your application might not be secure .

Because while Salesforce provides one of the most secure enterprise platforms available, developers and administrators can still introduce vulnerabilities through code, configuration, permissions, integrations, and design decisions.

That's where OWASP comes in.

The 2025 update shifts the conversation away from individual coding mistakes and toward systemic security weaknesses that affect the entire software lifecycle.

And honestly?

That sounds a lot like Salesforce.

🧠 My Learning Strategy: Stay Curious, Stay Secure

What is the OWASP Top 10?

If you have never heard about OWASP TOP 10: Your in for treat. The OWASP Top 10 is a globally recognized list of the most critical application security risks, it is not an be all and end all list but rather a guide on checks you should mark off ASAP before moving to other potential security risk. TL:DR(a Cheat sheet )

The 2025 release places greater emphasis on:

• Security design
• Configuration
• Supply chains
• Operational practices
• Error handling

Security is no longer just about code, Finally. It's about the entire system.

Why does it matter for Salesforce developers?

Because most Salesforce breaches don't happen because Salesforce failed. Actually I would put my head on the block and say all.

They happen because:

• Sharing was ignored.
• Permissions were too broad.
• Flows ran in system context.
• Integration users became administrators.
• Sensitive information was exposed.

When should I apply it?

Every time you: (TL:DR Every time you create a custom feature)

• Write Apex
• Build an LWC
• Configure permissions
• Create a Flow
• Design integrations
• Deploy packages
• Configure CI/CD pipelines

Security should be part of design, not an afterthought.

Where do these issues appear?

• Apex classes
• LWCs
• Flows
• Experience Cloud
• Integration users(ooooh the infamous user with every permission)
• Connected Apps(Full access (full) OAuth scope )
• DevOps pipelines(Usage of SAST or DAST)
• Third-party packages(can you say "supply chain attacks")

How do I fix them?

Let's walk through the OWASP Top 10 the SalesforceKlever way.

1. 🚫 Broken Access Control

"Just because Apex can access a record doesn't mean the user should."

This is why understanding the built in salesforce features is imperative.

Symptoms

• without sharing
• Missing CRUD/FLS checks
• Overexposed LWCs
• Guest user access

Salesforce recommends

• Use with sharing
• Use Security.stripInaccessible()
• Validate permissions
• Enforce least privilege

Broken Access Control remains the number one application security risk.

2. 🛠 Security Misconfiguration

"Most attacks don't require hackers. They require bad settings."

The problems always seem to start in development. The thing about developing feature at a higher pace is that most admins/developers tend to make the config use their profile settings( which is reasonably ) but when deadline creep up the testing is only done to test the use case and not the test the security.

Symptoms

• Excessive permissions
• Public Flows
• Guest users with access
• Weak session settings

Salesforce recommends

• Review profiles regularly.
• Harden session settings.
• Audit guest users.
• Minimize administrative access.

Security Misconfiguration moved from #5 to #2 in OWASP 2025.

3. 📦 Software Supply Chain Failures

"Every dependency becomes your responsibility."

This is one of the most dangerous on because if not properly vetted and tested in a sandbox. This can lead to data breaches which can go unnoticed.

Symptoms

• Unmanaged packages
• Unknown JavaScript libraries
• Untrusted GitHub actions
• External dependencies

Salesforce recommends

• Review package vendors.
• Audit dependencies.
• Secure CI/CD pipelines.
• Track external code sources.

This category replaces Vulnerable Components and greatly expands the focus to include the entire software supply chain.

4. 🔐 Cryptographic Failures

"Secrets should remain secret."

Well another situation where fast development and not checking whats pushed to your git repo can lead to serious problems.

Symptoms

• Hardcoded credentials
• Tokens stored in metadata
• Plain-text secrets

Salesforce recommends

• Use Named Credentials.
• Use protected settings.
• Consider Shield Platform Encryption.

Not every configuration value is a secret.

Treat credentials differently.

5. 💉 Injection

"If user input reaches your query, be careful."

In 2026, I would have hopped developers would know better but the allure of using dynamic soql is to great. So instead of forcing developers to stop salesforce has made life easier by creating a couple of methods

Dangerous

String query =
    'SELECT Name FROM Account WHERE Id = \'' + accountId + '\'';

String query =
    'SELECT Name FROM Account WHERE Id = \'' + accountId + '\'';

Better

Account acc = [
    SELECT Name
    FROM Account
    WHERE Id = :accountId
];

Account acc = [
    SELECT Name
    FROM Account
    WHERE Id = :accountId
];

Salesforce recommends

• Use bind variables.
• Validate input.
• Encapsulate query logic.

Injection remains important, but OWASP now emphasizes the underlying systems that allow it to happen.

6. 🧱 Insecure Design

"The most expensive vulnerabilities are architectural."

Symptoms

• Over privileged users
• Public automation
• Poor access design
• Missing threat modeling

Salesforce recommends

• Design for least privilege.
• Review abuse scenarios.
• Include security during architecture.

Security is not a deployment activity.

It's a design activity.

7. 🪪 Authentication Failures

"Authentication problems become identity problems."

Symptoms

• Missing MFA
• Excessive OAuth scopes
• Weak connected apps

Salesforce recommends

• Enforce MFA.
• Limit scopes.
• Review identity architecture.
• Use Salesforce Identity.

8. 🔄 Software and Data Integrity Failures

"Can you trust what you deploy?"

Symptoms

• Manual production changes
• Unknown deployment sources
• Unreviewed code

Salesforce recommends

• Use CI/CD.
• Require code reviews.
• Use source control.
• Validate deployments.

Trusted deployments are secure deployments.

9. 👁 Logging and Alerting Failures

"If you don't monitor it, you won't catch it."

Symptoms

• Missing logs
• No monitoring
• No alerts

Salesforce recommends

• Enable Event Monitoring.
• Log Apex exceptions.
• Review login history.
• Configure Transaction Security.

OWASP now emphasizes alerting in addition to logging.

10. ⚠ Mishandling of Exceptional Conditions

"Ignoring errors is still an error."

Symptoms

try {
    update records;
}
catch (Exception e) {
    // Ignore exception
}

try {
    update records;
}
catch (Exception e) {
    // Ignore exception
}

Or:

• Suppressing Flow failures
• Returning stack traces
• Continuing after security failures

Salesforce recommends

• Log exceptions.
• Fail securely.
• Surface meaningful errors.
• Never swallow exceptions.

This is a new OWASP 2025 category and is surprisingly relevant to Apex and Flow development.

😨 Gotchas to Watch Out For

• Some Flows execute in system context.
• Custom Metadata is not encrypted.
• LWCs do not automatically enforce FLS.
• Integration users often accumulate excessive permissions.
• Guest users remain a major attack surface.
• Temporary admin access tends to become permanent.

💭 Final Thought

The most dangerous Salesforce code usually isn't the code that crashes.

It's the code that works perfectly. The Flow that exposes too much, the Apex class that ignores sharing and the integration user with administrator access. The package nobody reviewed and the exception nobody logged.

OWASP 2025 teaches us something Salesforce developers need to hear:

Security isn't just about writing secure code.

It's about designing secure systems.

Because secure applications aren't built during penetration tests.

They're built during architecture discussions, code reviews, deployments, and permission assignments.

So the next time you build a Flow, deploy metadata, or expose an API, ask yourself:

🧠 "Am I building features that we can trust?"

Let's build secure applications the SalesforceKlever way. 🚀