[Query]: overly permissive access control

[felickz]

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

• I agree to follow this project's Code of Conduct

[felickz]

(just testing Copilot coding agent here)