Skip to content

fix: skip secure params lint for type aliases#19796

Open
nanookclaw wants to merge 2 commits into
Azure:mainfrom
nanookclaw:fix/secure-secrets-type-reference
Open

fix: skip secure params lint for type aliases#19796
nanookclaw wants to merge 2 commits into
Azure:mainfrom
nanookclaw:fix/secure-secrets-type-reference

Conversation

@nanookclaw

@nanookclaw nanookclaw commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

Description

Fixes #15086.

The secure-secrets-in-params rule was flagging parameters whose declared type is a user-defined type alias that resolves to string or object. Its quick fix then offered @secure(), but the compiler rejects applying @secure() to type aliases.

This updates the name-based heuristic to skip parameters whose declared type syntax resolves through a type alias/imported type alias, matching the compiler restriction that already reports DecoratorMayNotTargetTypeAlias. The default-value check still reports parameters that reference a secure parameter, so that existing security signal is preserved.

Added focused linter tests for object and string alias false positives, direct object behavior, and default values referencing secure parameters.

Checklist

Microsoft Reviewers: Open in CodeFlow

CompileAndTest("""
type SecureStringType = string

param password SecureStringType

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem like the right behavior - this should still be flagged

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 80867b9. User-defined type references with secret-like parameter names are flagged again unless the referenced alias resolves to a secure declared type.

}

type ContainerAppSecretListType = {
secureList: ContainerAppSecretType[]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite the name, this is not marked as @secure() and should continue to be flagged

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 80867b9. This unannotated alias case now produces the secure-secrets-in-params diagnostic; only @secure() type aliases are skipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The secure-secrets-in-params linter blocks the use of type references

2 participants