+ Start a Discussion

Protecting against XSFR/CSFR while auto-updating fields on page load

Hi folks,


We're getting ready to go through the security scan so we can take our app public on the AppExchange.  In our pre-scan report, however, we're getting a couple XSFR/CSFR reports.  Why?  When we have someone load a particular URL, we'll grab an Id from the URL params and use that to make a hard-coded update to the Id's record.  So, let's say this URL is used to update a custom object's checkbox field when loaded.  No login required, no cookie created.


That's it.  No data can be forced into the object's record from the URL, we've protected against XSS, and the change is hard-coded in the controller.


So, my question is this:  considering the limitation of this update, would the SFDC security review team flag this as an unpassable situation for their security review?  If so, are there other options that we can use (we don't want to require user button clicking or input to do something this simple ... they're being redirected to another page).


The security scanner (and I suspect the team as well) won't be happy about the fact that you are pulling the id from the URL.  While there isn't the opportunity to change the data written to the record, it is possible to manufacture ids and force the update against other records without the user necessarily knowing.  As to whether this will cause the security team to reject it, I suspect you'll have to have that discussion with them.  When we went through this a while ago we had the opportunity to talk to them, so you should have a chance to put your case.


Thanks for the feedback, that's super helpful.  Considering the use-case, I'm trying to think of any other alternatives that could be implemented.  If our goal is to be able to record information in a record based on a visitor simply loading a page, and we don't want to force them to click a button to do something behind the scenes that they shouldn't need to be worried about anyway, I'm not sure if there's a work-around available...but I'd be very interested to hear other's ideas.


This post below was interesting to read, not sure how their security process went...


XSRF Mitigation suggestions



Its only my opinion, but I'd expect that to be acceptable to the security team as the user has to click a button to make the action happen, and that button cannot be embedded into another web site.  The classic case for XRSF when DML is carried out in the page action is that a link to the page with a manufactured id could be embedded into a different site under an innocuous link and as long as the user has an active session on SFDC the change will happen.


I've also seen workarounds that use a javascript onload action to execute an actionfuncion that carries out the change.  While that will fool the security scanner, the net effect is the same and I'd expect the security team to spot that.


Again, only my opinion, but I'd have thought that simply updating a record to indicate someone has viewed the page should be acceptable as its only recording some information rather than modifying or deleting records.


Thanks again for the feedback.  I'll keep people posted as we go through the security process.  I definitely agree with the idea that this is a really innocuous situation, and I hope that we'll be able to convince the security team of this as well.