Skip to main content
Nintex Community Menu Bar

For a public access site that is using a SKUID page to display information, what security concerns come up and how can they be addressed?


If I have a page that receives a passed ID to do a query, someone can potentially pass a different ID and get information from that ID that they shouldn’t necessarily see. I can perhaps secure this using a “token” along with the ID to run the query, which is my current line of thinking, but what other things might someone exploit on a SKUID public site? Could they somehow (using javascript perhaps) modify the query to remove that token condition?


I could set up Salesforce object level permissions to be more aggressive, but in doing so it would really be an all or nothing on a per object basis rather than only allowing the user to query for information specific to them. Let’s say I want to expose the Invoice object to customers through the public site, but only want customers to be able to view their own invoices; how can this be secured? If we set up the pages in such a way that we have a user “log in” to the public site to view data specific to them, how might this sort of a technique be best secured?


Additionally, SKUID uses javascript for most of its functionality which runs in the user’s browser. Considering security concerns from the local processing nature of javascript, what stops the end user from accessing SKUID’s javascript functions on the fly if they know where to look / what functions to run. Does anything prevent someone from diving into the javascript in their local browser and looking at the local data or querying for information they shouldn’t see? What aspects of SKUID pages are secure and what aren’t, and how should a SKUID page be set up so it is secure on a public site? Can it really be fully secured?

These general security questions and I’m sure more I’m not yet thinking of are pertinent to keep in mind and address when designing a SKUID based public site. Is there any documentation to assist in identifying possible security holes that might exist in different ways of setting up a SKUID public site / setting up public pages? What are all the security related issues to be aware of when designing a SKUID public site?

Thanks!

Mark,

These are great questions around Skuid’s security model. First off, because of how Skuid sits on top of Salesforce’s platform, we totally respect Salesforce’s security model for your data. That means, Skuid does not allow users to access data they would not already be able to access by some other means on the Salesforce platform. For example, if you were to develop a custom, public-facing website without Skuid on Salesforce’s platform (e.g. via Salesforce’s own customization tools and your own custom code), you would still run into the same concerns of users being able to access other records via changing a URL parameter, making their own API callouts to Salesforce’s API, etc.

As far as our JavaScript API is concerned, you are correct: It is absolutely possible for users to access Skuid’s JavaScript functions on the fly, run them manually from the browser console with their own inputs, or even “overwrite” Skuid’s JS functions in the browser (not recommended, as it might “break” their Skuid page in runtime). We actually set it up this way by design, in order to provide maximum customization capability for users (https://docs.skuid.com/latest/en/skuid/javascript/skuid-javascript.html). However, while users may be able to use Skuid’s JavaScript API to access data that you are not already making available via your Skuid page setup, Skuid’s JS functions should NEVER expose data that users wouldn’t already be able to access via calls to Salesforce’s JavaScript API, or by running other callouts to Salesforce’s APIs (e.g. their REST or SOAP APIs) from the browser.

The way Skuid fetches data from the Salesforce database is all controlled on the server side via (1.) our managed Apex code (which users would not have access to), and (2.) Salesforce’s own native data access restrictions based on how your security model is set up. Therefore, we shouldn’t be exposing any data to the browser (client) that users shouldn’t be able to see based on how you’ve set up your Salesforce security model.

Skuid’s tools for limiting data that the user sees (e.g. model conditions, conditional rendering) are really designed as UX optimization tools, and are not intended to be used as security constraints. All of this handling should take place at the Salesforce configuration level.

It sounds like this comes down to more of a concern about your security setup within Salesforce. If Salesforce’s profile/permissions settings for a public-facing site don’t satisfy your requirements of being able to restrict users to seeing only certain records within an object, you may need to explore another solution involving authenticated users within Salesforce, rather than a public-facing site. I’d recommend doing a bit more research into Salesforce’s Profiles, Permission Sets, and Sharing Rules, and see if there’s a way to achieve your data access requirements via those tools.

For further info, see our “Skuid for Salesforce Evaluation Guide”, particularly the section on how Skuid works with Salesforce’s security settings: https://docs.skuid.com/latest/en/evaluation-guide/security/how-does-skuid-work-with-security.html#

Hope this satisfies your concerns. Please let us know if you have more questions!

Emily

Hi Emily,

Thank you for your reply. It would seem then that for a public site that needs to access data for certain users in particular, there is no way to really secure that site since you would need to enable the Public Access User to have access to the Salesforce objects, but cannot give that broad guest user only access to a subset of an object based on who is viewing the public page.

If I can ask one more question Emily,


Zach mentioned in another post that the javascript function skuid.sfdc.api.query(queryStr) uses system level permissions instead of user level permissions. For a public site, is this function accessible? Does it still use system level permissions?

Mark,
That is correct. If you’re looking for some sort of “public-facing” or customer-facing option on Salesforce, but with authenticated users that have access to a limited subset of records, I’d explore using Salesforce Communities. This might suit your needs, and Skuid does work within Communities as well.
Emily

I just saw your second question there, about the skuid.sfdc.api.query function. Do you mind pointing me to where Zach’s comment was about that function? Was that within the Skuid Community?

Sure Emily,


It was in this thread here commenting on my technique for a “modelLoader” function:


https://community.skuid.com/t/model-fieldsmap-field-encloseinquotes-displaytype-list-of-all-possible-field-displaytypes


One big concern I have with building this query client-side and using skuid.sfdc.api.query() is that you're avoiding all of Skuid's object-level and field-level security enforcement logic which is performed server-side as part of Skuid Model loads and our Apex logic. 

Hm, interesting… let me look into that, and I’ll get back to you.

Hey Mark, to follow up on this, it looks like I was going off of old information when I posted that concern — in our testing, the Salesforce REST API enforces object and field-level security correctly, so I’m retracting my previous comment about having concern with use of skuid.sfdc.api.query() — this should execute any SOQL queries that you provide to it with object-level and field-level security enforced, e.g. if you try to query on a field that you don’t have access to, the query will throw an error.

Reply


Sidebar Buttons
Nintex Community Home Contact Nintex Support Check Nintex Status
Terms & ConditionsCookie settings