Terraform Variable Defaults Checker

A Terraform variable block is part of a module's public contract. It tells callers which values they must supply, which values have fallbacks, what type is expected, whether null is accepted, and which values need special handling. Small mistakes here can spread across every environment that consumes the module.

Defaults are useful when one safe ordinary value fits most callers. An empty tag map or a disabled optional feature can reduce repetition without hiding intent. A credential-like fallback, a default with the wrong shape, or a required infrastructure identifier disguised as a harmless constant creates a different risk: plans may succeed with a value that should have been chosen explicitly.

Required input

A variable without a default. This can be intentional when no universal fallback exists.

Sensitive

A redaction setting for normal CLI and interface output; it does not keep the value out of state or plan files by itself.

Ephemeral

A Terraform 1.10+ setting for temporary values that should be omitted from state and plan files, with restrictions on where they may be referenced.

Nullable

A rule controlling whether callers may pass null. When null remains allowed, it can override a non-null fallback.

Required inputs and default coverage must be judged against the module's purpose. A reusable module may correctly require a region, network identifier, or account-specific name. A release template may instead expect safe defaults for most non-sensitive options. The useful question is not “Does every variable have a default?” but “Does every fallback make the interface safer and clearer for its callers?”

Static review has limits. Terraform expressions, type conversions, nested HCL, callers, providers, state, policy rules, and runtime behavior can change the real result. A source scan is a focused preflight for variable declarations; terraform validate, a plan, policy checks, and module-owner review remain necessary before release.

How to Use This Tool:

Review one coherent module or stack scope at a time so required-input policy and version assumptions stay meaningful.

1. Paste complete Terraform variable blocks or load one local text-based Terraform or HCL file. Keep the source at or below 5 MiB and remove credentials before review.
2. Give the scope a short Module or stack label that contains no secret or environment credential.
3. Choose Module contract when intentional required inputs are acceptable, Default hygiene when safe non-sensitive defaults are preferred, or Strict release when missing non-sensitive defaults need high-priority review.
4. Select the oldest supported Terraform target. This changes how ephemeral and deprecated arguments are judged.
5. Review Critical and High findings first. The Finding rows limit controls only how many sorted rows are shown and exported; totals and exposure counts still cover every finding.
6. Correct the source, then run Terraform validation and a plan in the intended module context.

Interpreting Results:

The decision follows the most consequential findings. Any Critical finding produces Blocked; otherwise any High finding produces High-impact review. Medium findings or a total risk score of at least 14 produce Review defaults. Remaining Low findings produce Polish contract, and no findings produce Default posture clear.

• A secret-like name is a heuristic signal, not proof that the value is a credential. Check the variable's real use and data flow.
• A masked default protects the report from echoing likely sensitive text; it does not prove the source contains no secrets.
• Low default coverage may be correct for a module whose callers must choose environment-specific values.
• A clear result means no configured scanner rule fired. It does not mean the HCL parsed or planned successfully in Terraform.

Technical Details:

The scanner finds quoted variable blocks, matches braces while accounting for strings and comments, and reads top-level attributes plus the count of nested validation blocks. It classifies literal defaults as null, string, boolean, number, list, object, expression, or absent before applying policy rules.

Transformation Core

The review path is source text → complete variable blocks → attributes and validation count → default posture → per-variable findings → severity sorting → summary decision. Concrete sensitive defaults are masked in result rows; non-sensitive defaults are shortened to 90 characters.

Rule Core

Formula Core

The risk score is an additive triage value; it is not a probability or a Terraform security rating.

C, H, M, and L are the counts of Critical, High, Medium, and Low findings. Findings sort by those weights, then source line, then variable name.

Default coverage divides variables with any declared default—including null—by all parsed variables.

The calculated percentage retains full precision before presentation. Source size, line count, variable count, validation-block count, and every severity total cover the complete scan even when the visible finding list is capped between 10 and 300 rows.

Privacy and Accuracy Notes:

Pasted and locally loaded source is scanned in the browser and is not uploaded. Even so, remove real credentials before pasting because a browser-local review is not a substitute for secret-handling policy.

• The scanner is not a complete HCL parser and can simplify complex expressions, heredocs, and nested structures.
• Name and credential-pattern checks can produce false positives and false negatives.
• Literal-shape comparison does not reproduce Terraform's complete conversion and validation behavior.
• Version rules reflect the selected target; rerun after changing the module's minimum Terraform version.

Worked Examples:

References:

• Variable block reference, HashiCorp Terraform Documentation.
• Manage sensitive data in your configuration, HashiCorp Terraform Documentation.