Description
When using SQL for Confluence on sites with untrusted users, you may need to employ security measures to control use. This describes some of the techniques for doing this. In some cases, you may want to employ multiple techniques together depending on factors like database being accessed. For instance, macro security can be applied no matter what other technique you want to use.
Technique | Description | Benefits |
---|---|---|
Macro Security for Confluence | Content using SQL macros can only be created or updated by trusted users while still allowing other users the ability to view the content. This is implemented by the Confluence administrator installing Macro Security for Confluence using UPM and configuring access. |
|
Database permissions | Database permissions for the user configured for the SQL data source can be restricted. For instance, view only authority. This is recommended when the only subset of access is needed, especially for browse only. |
|
Allow only SQL-query Macro | Some databases (like PostgreSQL) enforce a JDBC remote access mode for read-only. The SQL-query macro uses this support. This can be implemented by having the Confluence administrator disable the other SQL macros in the UPM. |
|
Allow only SQL-file Macro | The SQL-file macro only runs Confluence administrator controlled SQL. This can be implemented by having the Confluence administrator disable the other SQL macros in the UPM. See How to securely run SQL queries without page edit restrictions. |
|
Role-based security | Use database role security to control what data is available. |
|
Use parameter markers | Prevent SQL injection attacks by using parameter markers. This is only necessary when the SQL statements are partially constructed from user input - for example, using the Run Self-Service Reports for Confluence. See Wikipedia: SQL injection. Parameter markers are supported by SQL for Confluence. |
|
Confluence database access
If Confluence database access is defined via an application server data source, Confluence data can be accessed by the SQL macros using that data source unless other security techniques prevent access. This can be powerful in many circumstances but should be access controlled just like other databases. Direct access to a database circumvents application level security, so should always be considered. Even if you want to provide some level of access to the Confluence database, it is strongly recommended to create a separate data source for this access. Either duplicate the application server data source definition that Confluence uses and provide a different name (preferred) or create a profile-defined data source. To prevent access to the Confluence defined data source, either use Macro Security for Confluence to disallow access or define a profile-defined data source with the same name as the application data source and override the values or re-direct to some other data source.