Security Considerations

A full list of Security Advisories is available on GitHub.

Given the context of how SQLFluff is designed to be used, there are three different tiers of access which users may have access to manipulate how the tool functions in a secure environment.

1. Users may have edit access to the SQL code which is being linted. While SQLFluff does not execute the SQL itself, in the process of the templating step (in particular via jinja or dbt), certain macros may have the ability to execute arbitrary SQL code (e.g. the dbt run_query macro). For the Jinja templater, SQLFluff uses the Jinja2 SandboxedEnvironment to limit the execution on unsafe code. When looking to further secure this situation, see below for ways to limit the ability of users to import other libraries.

2. Users may have edit access to the SQLFluff :ref:`config-files`. In some (perhaps, many) environments, the users who can edit SQL files may also be able to access and edit the Configuration Files. It’s important to note that because of In-File Configuration Directives, that users who can edit SQL files which are designed to be linted, will also have access to the vast majority of any configuration options available in Configuration Files. This means that there is minimal additional protection from restricting access to Configuration Files for users who already have access to edit the linting target files (as described above).

3. Users may have access to change how SQLFluff is invoked. SQLFluff can be invoked either as a command line too or via the python API. Typically the method is fixed for a given application. When thinking about how to restrict the ability of users to call insecure code, SQLFluff aims to provide options at the point of invocation. In particular, as described above, the primary risk vector for SQLFluff is the macro environment as described in Templating Configuration. To restrict users being able to bring arbitrary python methods into sqlfluff via the library_path configuration value (see Library Templating), we recommend that for secure environments you override this config value either by providing an override option to the FluffConfig object if using the Python API or via the --library-path CLI option:

   To disable this option entirely via the CLI:

   $ sqlfluff lint my_path --library-path none
   

   To disable this option entirely via the python API:

   """This is an example of providing config overrides."""
   
   from sqlfluff.core import FluffConfig, Linter
   
   sql = "SELECT 1\n"
   
   
   config = FluffConfig(
       overrides={
           "dialect": "snowflake",
           # NOTE: We explicitly set the string "none" here rather
           # than a None literal so that it overrides any config
           # set by any config files in the path.
           "library_path": "none",
       }
   )
   
   linted_file = Linter(config=config).lint_string(sql)
   
   assert linted_file.get_violations() == []