OSS provides a multi-layered system for permissions and access control to secure your data. This topic provides an overview of the access control framework in OSS, helping you understand and compare the available methods to choose the best one for your specific needs.
Quick guide
Scenario | Recommended solution |
Keep data private and block unauthorized or anonymous access | Set the bucket ACL to private (default). |
Serve publicly readable static resources | Set the bucket ACL to public-read and configure hotlink protection to prevent unauthorized use. |
Grant multiple users access to a specific bucket | Use a bucket policy. A single policy can specify a list of allowed users. |
Centrally manage all resources a user can access | Attach a RAM policy to the user. |
Share resources with other Alibaba Cloud accounts | Use a bucket policy or implement cross-account access to OSS by using a RAM role. |
Provide differentiated access to the same bucket for multiple applications or teams | Use an access point. Each application or team gets a dedicated entry point and policy. |
Prevent accidental data leaks due to misconfigurations | Enable Block Public Access. |
Access OSS from client-side JavaScript in a browser | Configure cross-origin resource sharing (CORS). |
Define permission boundaries in a multi-account environment, such as enforcing the Block Public Access feature | Use a Control Policy. |
Authentication mechanism
OSS uses different authentication processes depending on the request type:
Signed requests: OSS first verifies the signature. It then evaluates the Control Policy (if any), RAM policy, bucket policy, and access control list (ACL) to determine whether to grant access.
Anonymous requests: OSS evaluates the Control Policy (if any), bucket policy, and ACL to determine if public access is allowed.
The authentication result can be one of three types: Allow (explicitly granted by a policy), Explicit Deny (explicitly denied by a policy, which has the highest priority), and Implicit Deny (denied by default if no policy grants access).
For the complete authentication flow, see Authentication process details.
Access control methods
ACL
An access control list (ACL) is the simplest way to control permissions. It uses predefined permission levels to set a resource's access state to public or private.
A bucket ACL controls the default access permissions for a bucket, while an object ACL controls permissions for an individual object and has a higher priority. If an object ACL is not specified, the object inherits the permissions from the bucket ACL. The following permission levels are supported:
Permission level | Effect |
private | The data is private. Only the resource owner or authorized users can access it. |
public-read | Anyone can read the resource. Only the resource owner or authorized users can write to it. |
public-read-write | Anyone can publicly read and write to the resource. |
ACLs only support predefined levels and cannot specify who is granted access or under what conditions. For more fine-grained control, use a bucket policy or a RAM policy.
Bucket policy
A bucket policy is a resource-based authorization policy attached to a bucket. It defines who can access the resources in the bucket. You can use it to grant permissions to RAM users, other Alibaba Cloud accounts, or anonymous users, and you can specify conditions such as IP address, VPC, or time.
When you need to grant access to the same bucket to multiple users, you can use a single bucket policy instead of configuring separate permissions for each user.
Tutorials: Use a VPC endpoint policy and a bucket policy to implement dual access control | Share data across departments by using a bucket policy
RAM policy
A RAM policy is an identity-based authorization policy attached to a user identity. It defines which OSS resources the user can access and is ideal for centrally managing permissions for a user or application across multiple buckets.
OSS provides system policies, such as AliyunOSSFullAccess and AliyunOSSReadOnlyAccess, that you can use directly. You can also create custom policies. You can use RAM roles to enable cross-account access and grant temporary authorization through Security Token Service (STS).
Tutorials: Use RAM roles to access OSS resources across Alibaba Cloud accounts | Use RAM policies to control access to OSS
Control Policy
A Control Policy in Resource Directory is an access control policy based on your resource structure, such as resource folders or members. It is mainly used to define permission boundaries. In a multi-account environment, you can use custom control policies to enforce security requirements across member accounts, such as requiring Block Public Access to be enabled on all buckets.
Comparison of policies
Aspect | Bucket policy | RAM policy | Control policy |
Configuration scope | On a bucket | On a RAM identity (user, group, or role) | On a resource structure (resource folder or member) in Resource Directory |
Management perspective | Resource-centric: "Who can access this resource?" | Identity-centric: "What resources can this identity access?" | Organization-centric: "What are the permission boundaries for the entire Resource Directory?" |
Anonymous access | Supported | Not supported | Not supported |
Recommendations: Use a bucket policy to efficiently grant multiple users access to the same resource. Use a RAM policy to intuitively manage all resource permissions for a single user. You must use a bucket policy to allow anonymous access. In a multi-account environment, you can use a Control Policy to define permission boundaries. These methods can be used together. OSS grants a request only when all applicable policies allow it.
Access points
An access point provides a dedicated entry point for accessing a bucket. When a single bucket needs to be accessed by multiple applications or teams with different permissions, you can create a separate access point for each. You can then use an access point policy to manage permissions for each access point individually, avoiding the need to maintain a single, complex bucket policy.
Each access point has a unique access domain name, access point policy, and network restrictions. When a user accesses OSS through an access point, a request is granted only if it is allowed by the access point policy, the bucket policy, and any applicable RAM policy.
Security features
Block Public Access
When enabled, Block Public Access overrides any public permissions granted by ACLs or bucket policies, preventing data leaks from misconfigurations. You can configure this feature at the account level (for all buckets), bucket level, or access point level, with higher levels taking precedence.
We recommend enabling this feature at the account level if you store sensitive data and do not require anonymous access.
Hotlink protection
Hotlink protection prevents unauthorized websites from linking to your OSS resources by checking the Referer header in HTTP requests. You can configure a whitelist (allow only specified domains) or a blacklist (deny specified domains). This feature helps prevent unauthorized use of resources like images and videos.
The Referer header can be spoofed. For higher security, we recommend using signed URLs.
Cross-origin resource sharing (CORS)
By default, browsers prevent JavaScript in a web page from accessing resources on a different domain. By configuring CORS rules, you can instruct OSS to include cross-origin headers in its response. This allows the browser to proceed with the request. This is useful for scenarios such as direct file uploads from a frontend or fetching resources for a web application.
Policy syntax
bucket policies, RAM policies, Control Policies, and access point policies are all defined in JSON format. The core elements include:
Element | Description |
Effect | The effect of the policy: |
Principal | The identity that is granted permissions (not required for RAM policies or Control Policies). |
Action | The operations that are allowed or denied, such as |
Resource | The resources to which the policy applies. |
Condition | The conditions under which the policy is in effect (optional). |
For the complete syntax and a list of actions, see Policy syntax and structure.