Warning about hardcoded secure parameter when that parameter is parsed from another secure parameter #13619
Labels
Milestone
Comments
stephaniezyen
added
bug
davidlloyduk
added a commit
to davidlloyduk/bicep
that referenced
this issue
Mar 25, 2024
anthony-c-martin
pushed a commit
that referenced
this issue
Apr 3, 2024
Fixes #13619 What was happening was that the linter rule was falling into the default behaviour and using the default error string as it wasn't checking it was a variable assignment. Added 1 unit test to cover the basic premise of the lint rule failure. One thing which did occur to me was that assignment of the secure parameter to a variable which is a hardcoded string isnt caught - but seemed like it should be a lint rule in of itself? Thoughts? eg. ``` var blah string = 'something' @secure() param myparam string = blah ``` Should we overcomplicate the lint rule to find a reassignment of a secure parameter? Seems an illogical but valid thing to do though
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bicep version
0.25.53
Describe the bug
If you define a second secure parameter that can either be defined separately or default to the value of another secure parameter, you still get the Warning:
Warning secure-parameter-default: Secure parameters should not have hardcoded defaults (except for empty or newGuid()).
Which in my opinion is incorrect, as it is not hardcoded, in fact, it is provided via another secure parameter anyway.
To Reproduce
@secure()
param appservice_password string
@secure()
param mqttReaderPassword string = appservice_password
Additional context
Yes, reusing passwords is not best practice, but having a single app key password that is only exposed via appsettings is the exact same security risk than having multiple of them in the same appsettings.
The text was updated successfully, but these errors were encountered: