# Seal Bicep input objects when extra properties must fail validation

> An object type alone can leave likely property-name mistakes as warnings; sealing makes the contract stricter.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-279-seal-bicep-input-objects-when-extra-properties-must-fail-validation/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:27:17+00:00
- Modified: 2026-09-10T01:23:49+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

An object type alone can leave likely property-name mistakes as warnings; sealing makes the contract stricter.

## Potentially affected

Bicep templates using user-defined object types for deployment parameters.

## DSE recommendation

Use sealed object contracts where unrecognized input must be rejected, and test both compiler and deployment validation.

## Article

## Source facts

Bicep user-defined types require CLI version 0.12.X or later and enable language-version 2.0 code generation. By default, an object type accepts additional properties; a likely misspelling can produce BCP089 as a warning rather than an error.

Applying @sealed() to the object type or parameter elevates that warning to an error. Azure Resource Manager also validates sealed parameters and fails deployment validation when they contain extra properties. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/user-defined-data-types).

## Applicability

Identify the pipeline’s Bicep version and which input objects have a deliberately closed schema. Do not apply a closed contract to an extension field that callers are intentionally allowed to populate freely.

## DSE recommendation

DSE recommends reviewing accepted property names with the module’s callers before sealing an input. Make the desired treatment of unknown fields explicit in the contract. Include a misspelled optional property and a genuinely additional property in the validation cases. Plan the change with existing callers rather than assuming every previously accepted input remains compatible.

## Verification

Run the current pipeline against valid input and the two invalid cases in a controlled scope. Retain compiler diagnostics and parameter-validation outcomes separately. Confirm that the expected valid properties still work and that an unrecognized field is not silently treated as an approved setting. Record the tested tool version with the contract change so later pipeline upgrades can repeat the same checks.

## Official references

[Microsoft Learn: User-defined types in Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/user-defined-data-types). Source retrieved September 9, 2026.

## Primary reference

- Name: User-defined types in Bicep - Azure Resource Manager | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/user-defined-data-types
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Seal Bicep input objects when extra properties must fail validation,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-279-seal-bicep-input-objects-when-extra-properties-must-fail-validation/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.