Public REST Services Security Concerns

[ZachBodenner]

Hello,

I have built a workflow for an end user that allows public individuals to write to a geodatabase feature class housed in our on-prem enterprise geodatabase. Basically, I have feature class "FC" that is published to our server (federated with Portal), referencing our GDB (not hosted). That federated web service is set to share publicly. Then, I developed a Survey123 form built off that published web service with the ability for anyone from the public to draw a line feature and complete the Survey (just a selection of the attributes from "FC"), and by completing it the line is written into FC. 

So my question is basically, this REST service, referencing our underlying geodatabase, is exposed to public editing. Is this bad practice? What are the security concerns involved with this setup? Our Network Admin seems relatively unconcerned; we have good firewalls and security in place throughout our IT environment, but I've had other users request similar applications and it feels...iffy to expose REST services to public editing. Any thoughts or input appreciated, thanks!

[jcarlson · Accepted solution]

Since you're publishing it as a feature service, it will be as secure as any other feature class. Members of the public won't be able to use that service to connect to your database or any other feature classes, just the one you share publicly.

The only real concern with publicly editable layers is data integrity. Do you have the proper editing controls in place to prevent users from altering or removing other submissions? Do you have ways of identifying or dealing with spamming / flooding the service?

Security, though, I think you're okay. If you're really concerned about it, have the public edits hit a hosted feature layer, then use a sync process to pull edits into your feature class. Or alternatively, use branch versioning and let the public edit a specific branch, then regularly validate the responses before posting them to the default version.

[ZachBodenner]

Okay thanks that's really helpful. For the more recent request, it would be the public using Survey123 to write to a related geodatabase table, so they wont actually ever see the feature class, even though it would have to be publicly available. I figure that would make the Hosted-to-GDB workflow not work so much since the relationship would be based on globalids.

But yeah, otherwise the original "FC" from the post above, the public only sees it through S123 and has write-only to that form. 

[jcarlson]

Sounds like it's pretty well-protected, then. How do the public get into the form? While it's nicer to have actual relationship classes in place, we have some forms that use globalids from features across disparate services to pipe into a single public layer using URL parameters.

Like: click on a bench at the park, the URL for "report issue" prepopulates the globalid with the parameter &field:asset_guid={globalid}&field:layer_id=some_layer, fields which are hidden in the form. This same issue reporting table can take responses relating to features from literally any layer with globalids, and the workers on the other end of that form can get a comprehensive list of reported issues.

[ZachBodenner]

Hmm, so I could create a hosted table that has a GUID, have my feature class layer visible to the public, then they click on that to open the S123 form and are basically dumping their report into a hosted table instead of a GDB table, if I have the right of it? 

I'm not sure if I like that any more or less than just exposing a GDB table for the purpose of my most recent user request, but that's super helpful to know!

[jcarlson]

Well, sort of. S123 needs a layer with geometry, so it'd need to be a point layer, but that's the gist of it. It all depends on the use case, and the GDB table is probably a lot simpler.