Hot answers tagged

29

Actually, this problem is due to the "aggressive" caching setting in LEX. Go to Setup Home > Security > Session Settings. Uncheck the option: Enable secure and persistent browser caching to improve performance. That should make it such that only a single page reload gives you new data/settings/etc.


12

You could write a helper method for this type of functionality: public Object flsGet(SObject record, SObjectField field) { return !field.getDescribe().isAccessible() ? null : record.get(field); } With this reusable method, you can now just one-line the check: Contact someRecord = [SELECT Name FROM Contact LIMIT 1]; system.debug(flsGet(someRecord, ...


12

Many fields cannot be changed once populated, such as Audit Fields. Run this script: for (SObjectField field : SObjectType.Account.fields.getMap().values()) { DescribeFieldResult describe = field.getDescribe(); if (describe.isCreateable() != describe.isUpdateable()) { system.debug(field); } } You should see something like: ...


9

Generally, code you've written is already CRUD- and FLS-safe, as long as you follow the basic guidelines regarding Visualforce elements (e.g. check FLS when not using apex:inputField, etc). You can always check FLS and CRUD in Apex Classes, Triggers, Batches, and Utility classes. FLS is almost never relevant in your code-- you generally want to perform ...


6

To disable the setting mentioned in Greg's answer for scratch orgs, disable S1EncryptedStoragePref2 in your project scratch def JSON: config/project-scratch-def.json { "orgName": "My Scratch Org", "edition": "Developer", "orgPreferences": { "enabled": [ "S1DesktopEnabled" ], "disabled": [ "...


6

You don't need to check every field that you query. The issue really boils down to who manages security for the field -- your app or the admin. With standard objects, the answer is always the admin. With custom objects, it depends on whether the field is user visible and is used by users or whether it is internal and used only by your app. Things like wizard ...


6

You could do something like: ((sObject)Type.forName('Account').newInstance()).getSObjectType().getDescribe().isAccessible(); Or you could do a global describe and get the values from the returned map Map<String,Schema.SObjectType> gd = Schema.getGlobalDescribe(); But you at least need to have the String of the Object name. If you don't at least ...


6

To help others who end up here, my response as an answer: From what you posted, looks like a false positive - so I would document it in review. Here is a link to a recent update from the SR team about how to document your false positives As much as anything, the team is looking for you to show awareness of implementing security on the platform, so if you ...


6

There are a few different ways to attack this problem, but the most common is to create a user with permissions, and then use System.runAs to execute your tests. I normally grant permissions to my packages via permset and not profiles, so I create a user, give it a permission set that I created, and then run the tests. That way I don't depend on the admin ...


5

Please refer to this knowledge article. Basically you just need to add some checks like if (!Schema.sObjectType.Contact.fields.Name.isAccessible()){ return ''; } or if (!Schema.sObjectType.Contact.fields.Name.isUpdateable()){ return null; } For dynamic check you could use Describe functionality. Basically you need to use several methods ...


5

Yes the CRUD/FLS are also important on the packaged objects .The decision to assign the permission set or not should be left with the org administrator and not something the package vendor can restrict or technically impose on them .So the CRUD/FLS checks are still important on the packaged objects and your apex code should impose CRUD/FLS checks .


5

The best option today I think is to largely avoid CRUD & FLS and enforce security via custom permissions aligned with your business processes but that is not really answering your question. Part of the difficulty here is first understanding where to perform CRUD & FLS checks. For me the best answer to that is on service entry since it allows callers ...


4

without sharing will not reinforce SFDC field level access and visibility, so you will be running your class on system context. In system context, Apex code has access to all objects and fields— object permissions, field-level security, sharing rules aren’t applied for the current user. This is to ensure that code won’t fail to run because of ...


4

Platform Encryption will go further than just preventing the users from seeing data, it will also encrypt the fields at the database level. For example, you can't even issue a SoQL query doing an "Order By XXX" if that field is encrypted. Also, PE lets you encrypt fields not subject to FLS (Account and Contact name, for example). In those cases, users will ...


4

Don't know of any tools that do this, but I'd do one of the following: Update a single profile via the UI to match the appropriate FLS, and then update the other profiles within the force.com IDE. i.e. copy and paste the XML from one profile on to the others. Be careful that you don't override any other values you care about. You'd probably want to do a ...


4

The only reasonable method I know of is to use a try-catch block: try { record.put(someField, someValue); } catch(SObjectException e) { // Field could not be written } Unfortunately, this is an expensive construct (~30ms per failed access), so you might want to at least pre-validate that it is !(isCalculated() || isAutoNumber()).


4

Checkmarx is not "useless," and, in fact, is very good at what it does. However, that's not to say that false positives are not possible. It can make mistakes. However, whenever you get a flag like this, you should check and see if it is a legitimate problem or not. If it is a false positive, document it and go on. Flags are not automatic rejections for ...


4

You cannot update Auto Number fields, by nature. If you want to have a Name field that includes an Auto Number as well as some text derived from other fields on the record, you should add a non-Name Auto Number field to your object. You can then use Process Builder to populate the Name field with a formula incorporating that Auto Number field along with ...


3

After our meeting with a rep who walked us through Shield in more detail, he said basically there are two reasons to use Platform Encryption: You are worried someone is going to physically steal a hard drive from Salesforce's data centers. The government (or your internal compliance team) tells you that you have to. It sounds like HIPAA actually doesn't ...


3

The main advantage of Platform Encryption versus Classic Encrypted Custom Fields is: Transparency for business critical Platform features, such as search, workflow, and validation rules You'd have to invistigate requirements for private health records storage, as FLS would not be an option in case of: Privacy policies, regulatory requirements, and ...


3

So Yes its of course possible you can do it in two ways (which essentialy are the same) Schema.sObjectType.Account.isUpdateable() and Account.sObjectType.getDescribe().isUpdateable() if (!Schema.sObjectType.Account.fields.Name.isUpdateable() && !Schema.sObjectType.Account.fields.BillingStreet.isUpdateable() ){ update acc; } That ...


3

You cannot change field level security by a workflow. However, you could do something like this: Create a new record type for your object Create a new page layout (on which you show this specific field) and assign it to the record type Create a workflow rule based on your criteria + field update that changes the record type


3

All records that you can view in the UI should have an Id, because that's how they're displayed and referenced in the database. There are actually a small handful of objects that either do not have an Id (you can query the field but all values will be null), do not have a unique Id (e.g. the Id field will contain duplicates), or do not have an Id field you ...


3

FLS is not automatically enforced just because you used "with sharing." You must check for access to the field before you display it to the user. Typically, if you use apex:inputField or apex:outputField, Visualforce will "protect" you from casually displaying data that should not be shown, but if you use other types of elements, like apex:outputText, you ...


3

The approach we took was to provide a special class, e.g. SecurityUtils, with a bunch of static methods on it that take the DescribeSObjectResult(s) or DescribeFieldResult(s) to be checked, e.g.: // Returns true if the user has access to all the specified fields public static Boolean canAccessFields(DescribeFieldResult[] fields) or // Throws an exception ...


3

TBH, considering that new security features are on the way but not quite GA yet, maybe your best bet is just to write your own central helper classes that will handle CRUD/FLS to exactly the extent that is needed to pass review. Later when the new tools go GA, you can then probably reduce the complexity of the helper classes by refactoring them to use the ...


3

The most voted advice will get you failed at the security review. End-users rely on CRUD/FLS configurable from UI Setup, and they will get quite surprised that your app does not respect the standard platform access restriction functionality. My advice is to check for CRUD/FLS inline, no libraries, as close as possible to the code that accesses the object, i....


2

Modify-all-data permission refers to the ability for a user to have access to all record data, bypassing role hierarchy security, and field read-only criteria. Field Level Security, will permanently hide those fields for specified profiles, as this indicates that certain profiled are not permitted access. Both fields, along with some others I have noticed ...


2

Yes, you can migrate FLS using the Eclipse IDE or Metadata API. Basically, create a "package.xml" that contains both the objects to migrate permissions for and the profiles to export in a single file, then perform the retrieve call. The profiles directory will include one XML file per exported profile that will include both the object and field level ...


2

Quickly after posted the question I found the answer: Customize Application. if anyone stumbles on this there's a knowledge base article which lists all the system permissions.


Only top voted, non community-wiki answers of a minimum length are eligible