Query Type
Security
Query Description
Check if there is a query for this, else create it -
This query should identify the following issue(s):
One of the most common (and high‑impact) vulnerabilities in Bicep templates is overly permissive access control — especially broad role assignments (RBAC) or wide-open network exposure (e.g., 0.0.0.0/0, public access enabled) when it isn’t necessary. Let’s focus on RBAC drift: granting powerful roles at too large a scope.
Why it happens:
Convenience: assigning Owner/Contributor at subscription or resource group scope instead of scoping to just the resource.
Copy/paste of sample code that uses built‑in broad roles.
Lack of parameter validation (e.g., letting a param pick any roleDefinitionId).
Automations (CI/CD) given excessive privileges instead of narrowly scoped custom roles.
Why it’s risky:
Expected Severity
Medium
Code Example
Privilege escalation: A compromised principal with Contributor can often create resources (incl. automation accounts, functions) to gain further access.
Lateral movement: Broad scope means more blast radius.
Harder to audit & enforce least privilege.
What it looks like (insecure example):
@description('Service principal object ID')
param spObjectId string
// Broad "Contributor" at subscription scope
resource subRole 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
name: guid(subscription().id, spObjectId, 'contributor-assignment')
scope: subscription()
properties: {
roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c') // Contributor
principalId: spObjectId
principalType: 'ServicePrincipal'
}
}More secure pattern:
Narrow scope (e.g., a single storage account).
Use a least‑privilege built‑in role (e.g., Storage Blob Data Reader) or a custom role.
Optionally gate the role creation behind a parameter with allowed values.
@allowed([
'ba92f5b4-2d11-453d-a403-e96b0029c9fe' // Storage Blob Data Reader
])
@description('Role definition ID to assign (restricted to approved least‑priv roles).')
param roleDefinitionId string
@description('Service principal object ID')
param spObjectId string
@description('Deploy RBAC assignment (toggle).')
param enableScopedAccess bool = true
resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
name: 'app${uniqueString(resourceGroup().id)}'
location: resourceGroup().location
kind: 'StorageV2'
sku: { name: 'Standard_LRS' }
properties: {
allowBlobPublicAccess: false
minimumTlsVersion: 'TLS1_2'
supportsHttpsTrafficOnly: true
}
}
resource scopedRole 'Microsoft.Authorization/roleAssignments@2022-04-01' = if (enableScopedAccess) {
name: guid(stg.id, spObjectId, roleDefinitionId)
scope: stg
properties: {
roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
principalId: spObjectId
principalType: 'ServicePrincipal'
}
}References
CWE-284: Improper Access Control (umbrella category), MITRE ATT&CK (e.g., T1098 Account Permissions Modification, facilitated by misconfig)
Code of Conduct
Query Type
Security
Query Description
Check if there is a query for this, else create it -
This query should identify the following issue(s):
One of the most common (and high‑impact) vulnerabilities in Bicep templates is overly permissive access control — especially broad role assignments (RBAC) or wide-open network exposure (e.g., 0.0.0.0/0, public access enabled) when it isn’t necessary. Let’s focus on RBAC drift: granting powerful roles at too large a scope.
Why it happens:
Convenience: assigning Owner/Contributor at subscription or resource group scope instead of scoping to just the resource.
Copy/paste of sample code that uses built‑in broad roles.
Lack of parameter validation (e.g., letting a param pick any roleDefinitionId).
Automations (CI/CD) given excessive privileges instead of narrowly scoped custom roles.
Why it’s risky:
Expected Severity
Medium
Code Example
Privilege escalation: A compromised principal with Contributor can often create resources (incl. automation accounts, functions) to gain further access.
Lateral movement: Broad scope means more blast radius.
Harder to audit & enforce least privilege.
What it looks like (insecure example):
More secure pattern:
Narrow scope (e.g., a single storage account).
Use a least‑privilege built‑in role (e.g., Storage Blob Data Reader) or a custom role.
Optionally gate the role creation behind a parameter with allowed values.
References
CWE-284: Improper Access Control (umbrella category), MITRE ATT&CK (e.g., T1098 Account Permissions Modification, facilitated by misconfig)
Code of Conduct