permalink: tools/ order: 2 ---

Apex Security Accelerator

Write secure Salesforce code. Fast. Free. Pass Salesforce's Security Review or internal audits in record time.

Install Now API Docs

Secure code

Ensure your Salesforce Apex code enforces configured CRUD & FLS permissions.

Faster go-to-market

Spend less time writing (and testing) security checks, and pass Salesforce's security review faster.

Simple API

Developers will feel right at home with an API that mirrors Salesforce's, making refactoring existing codebases fast.

Apex & Security Review

When Salesforce Apex interacts with the database, it does so with full system administrator permissions ignoring the CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) configured on the user's security profile. Because of this, Salesforce developers can unknowingly make data visible or editable. What good is all that platform security, if Apex ignores it?

This one "gotcha" is often overlooked by ISVs new to Salesforce development and is one of the most common reasons for failing Salesforce security review.

Foglight's Apex Security Accelerator enables Salesforce Apex developers to quickly and automatically enforce configured security for the running user. Our package has a simple API that will feel familiar to Apex Developers and supports enforcing any mix of CRUD, FLS, or Sharing Rules (or none at all when needed).


{% for apex_example in site.apex_examples %}

{{ apex_example.description }}

{{ apex_example.output }}
{% endfor %}


Where's the risk?

​Generally speaking, CRUD/FLS enforcement should be performed anytime a user would be able to view or modify data they shouldn't be able to, directly or indirectly. The typical "vectors" where CRUD/FLS enforcement is needed, but is often overlooked:

  • Apex methods with the webservice keyword & Apex Rest services.
  • Apex methods annotated with @RemoteActions.
  • Apex methods annotated with @AuraEnabled.
  • Visualforce pages with custom Apex Objects that proxy data to/from the Database.

What about with sharing?

The with sharing keyword in Apex only tells the platform to enforce sharing rules. Sharing rules govern a users ability to view or modify a record. They do not define what objects or fields a user is permitted to view or modify. Just because a user is granted sharing to a record, doesn't mean their Profile or Permission Sets enable access to the object or the fields on that object.

Spring ‘19

Until now, Salesforce has not made validating CRUD/FLS very easy (hence our package). But, Salesforce has seen how difficult this is for developers and are making progress to address this.

With Spring '19, Salesforce is releasing a BETA feature for the SOQL language that enforces CRUD/FLS on queries. It's still BETA (re: may break or just not work), has a few shortcomings (enforcement is all-or-none for CRUD & FLS, and errors don't tell you which objects/fields are inaccessible), and won't work for DML or SOSL. Until they support DML, SOSL, and SOQL in GA, Foglight CFLS is the simplest approach.

CRUD/FLS enforcement really should be a feature baked into the platform at the language level, so this is a very welcome feature.

Pricing & Terms

It's free to use. No catch. We've released it as a managed package making it easy to install. This also allows us to quickly push upgrades when we find bugs or add features. If you discover a bug, or want some features, contact us. Also, our liability is the same as the price paid: nothing.