By default Salesforce allows the guest user to be granted 'Create' and 'Read' sharing access to standard object records (for the purpose of this question, let's consider Account). It makes sense that in the standard sharing model you cannot enable 'Edit' access because this would remove all security from your data and any user could change your Salesforce data.

However, with a little bit of custom work some security could be added to allow guest users to securely change some data. Let's say I have a field on Account called My_Field__c that I would like my customers to be able to update under some scenarios. Does anyone see any inherent security risks in the following setup and/or have any insight on how Salesforce might view this custom override to the default sharing model?

  • Add a new custom field Allow_External_My_Field_Update__c to Account that indicates this record is available for customer editing.
  • Create a sharing rule to allow site guest user Read access when Allow_External_My_Field_Update__c is true.
  • Create a custom External_Id__c field containing a secure, non-sequential Id value. We don't want to use the standard Salesforce Id because these are sequential and easy to guess. This will be given to the customer so they can update their My_Field__c value in our system using a URL like https://my-force-com-site.com/updatedetails?a=SFGH40MTdoyTINd0eqb99rENNdcylJQZ07B2vJj5easOxMEtin0e3NVa4oyj
  • Create a Visualforce page for the editing that loads records with sharing using the External_Id__c field.

This is now the part that seems the least straight-forward to me. We can give the Site Guest user 'read-only' access to a number of fields with Field Level Security but because they do not have top-level Edit access to the object, Visualforce apex:inputField tags will render as read-only and we cannot check isUpdateable() from Apex because it will always say false. However, we can do the following:

  • Store the Salesforce Account Id in a temporary variable in Apex in the constructor.
  • Clear the Id from the Account in the constructor. (The page now views the Account as a new record and FLS behaves as expected with respect to read/edit access to specific fields).
  • On save, place the Account Id back onto the record, ensure that the user has isCreateable() access to all the fields on the Account record, then perform an update call.

This accomplishes what I am looking for from a technical standpoint but does anyone see any big issues here or egregious sharing model violations?


I just want to add a note that I am aware I could use an authenticated community user to achieve full security. However this update that is being made is incredibly infrequent per customer and requiring people to set up a user before performing it will be a big road-block. Also, there is a non-insignificant increased cost to acquiring blocks of licenses from Salesforce (especially if we want access to sharing).

Edit 2

To narrow the scope of this question a little, let me add some additional detail. I understand that in passwordless security there is a non-zero chance that a guess could be made for an access token. This can be mitigated by using long access tokens generated with randomness from the Apex Crypto class. I am more interested in any non-brute force risks here that are unique to the Salesforce platform. For example, if Salesforce allowed guest access to the REST API, then someone could simply execute a SOQL query via REST API to list all Accounts that they could edit, then proceed to make edits to them with other REST API calls. However, Salesforce does not allow unauthenticated access to the REST API (nor do they allow loading other standard pages to list records on a Force.com site).


2 Answers 2


Regardless of what you do, the Account object is not directly editable by external users who haven't been authenticated through the UI. That having been said, there are ways in which you can "authenticate" to your satisfaction to allow users to update a specific field indirectly.

One, would be to use a "form" they submit that is then processed via workflow of some kind or a trigger that updates Account when submitted from your site. The user's email address could be used as an external Id for them along with other information to validate the user has sufficient knowledge of the account to make the change.

Web-to-lead with it's Lead handling Rules can be used to process the form for you and kick off either a trigger or PB to update the Account. You'd also want to use workflow to send a confirmation to the email address of the change which includes a reply link in the template that if clicked, sends a form back to undo the changes made in the update.

The solution I'd recommend would be to have a button that would be clicked to send an email to the account holder's email address that's on record (presumably not displayed in the record), requesting to change their information. If they receive it, they can then follow a link to a form you provide someplace on your site (hidden except by direct link) which they can submit for you to process as previously described.

There are other ways using a custom object as a "mirror" along with a trigger or Process builder/flow that can border on violating the TOS depending on how the information is surfaced. More than anything, it's a matter of how much risk to the integrity of your database that you're willing to accept.

  • Thanks for offering up some other alternatives (I would not have thought to use web-to-lead for this). Do you know where to find the full Terms of Service that would govern a design like this? I am only familiar with the MSA when you sign up for a new DE org and the security review rules but neither of those contain anything pertaining to this type of setup.
    – dsharrison
    Commented Mar 20, 2017 at 17:22
  • Its the interpretation of the Site.com User License that applies to your situation. I couldn't find anything more specific.
    – crmprogdev
    Commented Mar 20, 2017 at 17:51
  • Thanks! Salesforce has a VAST amount of legal documentation I frequently find it challenging to locate things.
    – dsharrison
    Commented Mar 20, 2017 at 17:53

There is a glaring issue, I can brute force your page until I find accounts I can edit. You're opening up a security hole which is always a no-no. Without full authentication, you probably shouldn't let your users update data with 1 very annoying exception.

The U.S. email spam law (CAN SPAM) makes it illegal to require a login to unsubscribe from mailing lists. So if you're page is related to subscribe/unsubscribing from emails, go for it!

That being said, it's obviously risk vs. reward. How sensitive is the data? If someone were to brute force your page and ruin your entire database, what impact would that have on the business? Does your company have any security policies against this? Does your company have a department dedicated to information security that you can run this plan through?

We can't account for your own personal situation or your own company policies, if you evaluate it and decide that it's worth the risk, do it and pray it works out for the better.

Final note: this question is likely to spawn a discussion which is against the stack meta. https://stackoverflow.com/help/how-to-ask Stick to questions with concrete/factual answers rather than opinion based answers.

  • 1
    Using alpha-numeric characters for the access id with a length of 20 would give us 2.4596806e+36 permutations. The Force.com sites limit of 1,000,000 page views per 24 hours would mean that the site would almost certainly hit a limit before an id was successfully brute forced, although that is not guaranteed. Can you elaborate a bit on what about the question is against the stack meta? Passwordless authentication does not seem to be a matter of opinion and I am genuinely wondering if someone has had success implementing it on Salesforce, has hit any pitfalls, or has any helpful resources.
    – dsharrison
    Commented Mar 18, 2017 at 4:18
  • I have had success implementing it specifically for the email reasons I've mentioned above. It works and we haven't had any issues security wise (people unsubscribing contacts from mailing lists or brute force attempts) but that doesn't mean it's not possible. As for stack meta, there are specific points against asking for resources or general experience based questions. Your question does not have a concrete answer and will spawn more of a discussion (many many many answers to this post) which is not what stack exchange is for.
    – gNerb
    Commented Mar 18, 2017 at 17:02
  • Fair enough, I'll close this guy down and open up some smaller and more direct questions.
    – dsharrison
    Commented Mar 18, 2017 at 17:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .