Is your feature request related to a problem? Please describe.
Currently, Hasura's query-log outputs the exact variables used in GraphQL queries and the prepared_arguments sent to the database in plaintext. In real-world production environments, these often contain sensitive information or PII (e.g., passwords, emails, SSNs). Having this sensitive data flow directly into centralized logging systems poses a significant security and compliance risk (e.g., SOC2, GDPR).
The limitation of the current workaround:
At present, the only way to prevent this sensitive data from leaking into logs is to completely disable the query-log type via the HASURA_GRAPHQL_ENABLED_LOG_TYPES environment variable.
However, this "all-or-nothing" approach is an extreme and impractical workaround for production environments. Disabling query-log completely blinds the engineering and operations teams. It results in the loss of critical observability data—such as the GraphQL query strings, operation names, and performance metrics (execution times) of harmless queries. This forces users into an unacceptable trade-off between security and observability.
Describe the solution you'd like
I would like to propose a feature to automatically mask specific JSON keys within the variables object of the query-log before they are emitted, allowing teams to keep query-log enabled safely. This proposal is intended for the Hasura v2 engine.
Configuration:
Introduce a new environment variable and CLI flag to specify a comma-separated list of keys to mask:
- Env Var:
HASURA_GRAPHQL_LOG_MASKED_VARIABLES="password,email,ssn"
- CLI Flag:
--log-masked-variables="password,email,ssn"
Behavior:
When generating the query-log, the engine will recursively traverse the variables JSON payload. If any object key matches the configured list, its value will be replaced with a string "[MASKED]".
Describe alternatives you've considered
Metadata vs. Environment Variables:
I considered adding this configuration to the Hasura metadata. However, since logging is an infrastructure/operational concern rather than a schema definition concern, using an environment variable aligns much better with Hasura v2's existing design philosophy (similar to HASURA_GRAPHQL_ENABLED_LOG_TYPES).
Implementation Plan & Performance Considerations
Since this logic runs on every logged request, performance is critical. The proposed implementation plan is:
- Parse the comma-separated string at startup and store it as a
HashSet Data.Aeson.Key within the server options. This avoids per-request Text to Key conversions.
- Implement a pure recursive function using
aeson to traverse the JSON.
- Early Return: If the
HashSet is empty (default behavior), the traversal is completely skipped, returning the original Value in O(1) time, ensuring zero performance degradation for users who don't use this feature.
Related Issues
This proposal directly addresses the core request in:
It also shares a similar security/compliance mindset with:
I would love to contribute to Hasura by working on this feature for v2. This will be my first time contributing to the Hasura engine (and to a large Haskell codebase), so please forgive any initial clumsiness on my part. I am eager to learn and follow your guidance!
Please let me know if this design approach looks good to the maintainers, and I will be happy to open a PR.
Is your feature request related to a problem? Please describe.
Currently, Hasura's
query-logoutputs the exactvariablesused in GraphQL queries and theprepared_argumentssent to the database in plaintext. In real-world production environments, these often contain sensitive information or PII (e.g., passwords, emails, SSNs). Having this sensitive data flow directly into centralized logging systems poses a significant security and compliance risk (e.g., SOC2, GDPR).The limitation of the current workaround:
At present, the only way to prevent this sensitive data from leaking into logs is to completely disable the
query-logtype via theHASURA_GRAPHQL_ENABLED_LOG_TYPESenvironment variable.However, this "all-or-nothing" approach is an extreme and impractical workaround for production environments. Disabling
query-logcompletely blinds the engineering and operations teams. It results in the loss of critical observability data—such as the GraphQL query strings, operation names, and performance metrics (execution times) of harmless queries. This forces users into an unacceptable trade-off between security and observability.Describe the solution you'd like
I would like to propose a feature to automatically mask specific JSON keys within the
variablesobject of thequery-logbefore they are emitted, allowing teams to keepquery-logenabled safely. This proposal is intended for the Hasura v2 engine.Configuration:
Introduce a new environment variable and CLI flag to specify a comma-separated list of keys to mask:
HASURA_GRAPHQL_LOG_MASKED_VARIABLES="password,email,ssn"--log-masked-variables="password,email,ssn"Behavior:
When generating the
query-log, the engine will recursively traverse thevariablesJSON payload. If any object key matches the configured list, its value will be replaced with a string"[MASKED]".Describe alternatives you've considered
Metadata vs. Environment Variables:
I considered adding this configuration to the Hasura metadata. However, since logging is an infrastructure/operational concern rather than a schema definition concern, using an environment variable aligns much better with Hasura v2's existing design philosophy (similar to
HASURA_GRAPHQL_ENABLED_LOG_TYPES).Implementation Plan & Performance Considerations
Since this logic runs on every logged request, performance is critical. The proposed implementation plan is:
HashSet Data.Aeson.Keywithin the server options. This avoids per-requestTexttoKeyconversions.aesonto traverse the JSON.HashSetis empty (default behavior), the traversal is completely skipped, returning the originalValueinO(1)time, ensuring zero performance degradation for users who don't use this feature.Related Issues
This proposal directly addresses the core request in:
It also shares a similar security/compliance mindset with:
I would love to contribute to Hasura by working on this feature for v2. This will be my first time contributing to the Hasura engine (and to a large Haskell codebase), so please forgive any initial clumsiness on my part. I am eager to learn and follow your guidance!
Please let me know if this design approach looks good to the maintainers, and I will be happy to open a PR.