Application Security

All of Rizing Geospatial's products provide safeguards to help prevent SQL injection attacks by making use of paramaterized SQL queries within the .NET framework. While there are safeguards in place to prevent SQL injection attacks, within Rizing Geospatial's products, the recommended data access architecture is intended to provide the greatest defense mechanism. Securing data access via connection account privileges and application user/role/privilege assignment is critical to mitigating the risk of unintended server and database access. This is particularly important due to the fact that some functionality in Rizing Geospatial's products do require some level of dynamic SQL input. It is critical that only authenticated and trusted users have access to this functionality. All database connections to the transactional data should be configured to use a read-only connection. See Data Flow and Connections for more details.

Note: ArcGIS Server does include a security option to help prevent SQL injection attacks through the use of "standardized queries" functionality, which prevent the use of database-specific functions and syntax from being used within a supplied map service query "where clause". This security measure is turned on by default in ArcGIS Server. More information can be found here: ArcGIS Server: About standardized queries

The application’s security policy can be configured to use a number of different authentication and authorization mechanisms. See the Authentication topic for details on the supported security settings and how to configure them, as well as the other Security section topics.

Application security happens at the web service level. This means that authorization and authentication must be satisfied (based on the configuration) for any service/endpoint to be consumed. The application uses a token-based authentication system. This means that the user will first need to provide a set of credentials to verify who they are. The application will take those credentials and generate a token with an expiration date that can be passed by any subsequent requests to services for authentication. The application will cache the token that it receives after “logging in” and will pass that token as “Authorization” header in the HTTP request for every request made to the application services.

In order to properly secure the data transactions between the web application and the services, HTTPS (SSL) must be configured and used on the application server. If HTTPS is not used then the HTTP traffic could potentially be “sniffed” by anyone else on the network.