XEIZE
/Vulnerability documentation/IaC/Terraform/Alibaba Cloud/OSS bucket policy contains wildcards in actions and principals

OSS bucket policy contains wildcards in actions and principals

Restrict wildcard grants in OSS bucket policies to the principals, actions, and resources needed to prevent unintended data access and changes.

Description

Wildcard grants for both actions and principals in an OSS bucket policy can provide more access than needed. oss:* covers a broad set of actions, whereas a wildcard such as oss:Get* identifies a particular action family and does not itself grant writes or deletes. Review the actions together with their bucket and object paths.

Effective access depends on policy conditions, explicit denies, ACLs, and Block Public Access. acl = "private" alone does not block all policy-based access. In OSS, an empty Principal array also means all principals; do not use it to restrict access.

Potential impact

  • Objects with effective public read permission may disclose their contents beyond the intended audience. An action such as oss:Get* does not itself imply permission to write or delete.
  • If a wildcard action range includes writes or deletes and applies to the resource, principals that do not need those permissions may be able to change or delete data.
  • Permission to change bucket settings can allow changes to access controls or other configuration. Check each operation's restrictions and resource scope.

Remediation

  • Specify the required principals, actions, and bucket or object paths. Remove unnecessary wildcard grants, and do not include writes or administrative actions merely to support public reads.
  • Review policy conditions, explicit denies, ACLs, and Block Public Access together. Verify permissions against valid policies and the actual request conditions.
  • Inline policy has been deprecated since provider version 1.220.0. Manage new configurations with alicloud_oss_bucket_policy, and verify that required permissions remain intact when migrating an existing configuration.

Examples

These examples compare an allow statement with an explicit deny using the legacy inline policy form supported in provider 1.293.0. Choose an available, unique bucket name and update the policy's resource paths to match.

Broad action grant

hcl
resource "alicloud_oss_bucket" "bucket-policy1" {
  bucket = "bucket-1-policy"
  acl    = "private"

  policy = <<POLICY
  {"Statement": [
    {
        "Action": [
            "oss:*"
        ],
        "Effect": "Allow",
        "Principal": [
            "*"
        ],
        "Resource": [
            "acs:oss:*:*:bucket-1-policy",
            "acs:oss:*:*:bucket-1-policy/*"
        ]
    }
  ],
   "Version":"1"}
  POLICY
}

This statement intends to grant oss:* on the bucket and its objects to all principals. Check Block Public Access and operation-specific restrictions, and grant only the actions and principals that are required.

Broad explicit deny

hcl
resource "alicloud_oss_bucket" "bucket-policy1" {
  bucket = "bucket-1-policy"
  acl    = "private"

  policy = <<POLICY
  {"Statement": [
    {
        "Action": [
            "oss:*"
        ],
        "Effect": "Deny",
        "Principal": [
            "*"
        ],
        "Resource": [
            "acs:oss:*:*:bucket-1-policy",
            "acs:oss:*:*:bucket-1-policy/*"
        ]
    }
  ],
   "Version":"1"}
  POLICY
}

When this explicit deny applies, it can block required operations too. Remove or narrow unnecessary grants while preserving the access that authorized users need rather than applying this blanket deny unchanged.

References

XEIZE DocumentationTechnical support