All Products
Search

This Product

    Object Storage Service:Overview of permissions and access control

    Document Center

    Object Storage Service:Overview of permissions and access control

    Last Updated:Mar 19, 2026

    By default, OSS resources — buckets and objects — are private. Only the resource owner or authorized users can access them. To grant third-party access, OSS provides several access control mechanisms, each suited to different scenarios.

    For most use cases, RAM policies and bucket policies are the recommended approach. ACLs (bucket ACL and object ACL) offer simpler setup but less flexibility — prefer RAM policies or bucket policies for fine-grained, maintainable access control.
    MethodDescriptionWhen to use
    RAM policyA user-based authorization policy managed through Resource Access Management (RAM), Alibaba Cloud's centralized access control service. Attach policies to RAM users, user groups, or RAM roles to control their OSS permissions.Grant OSS permissions to identities within your Alibaba Cloud account. Recommended for managing permissions across multiple users, groups, or roles.
    Bucket policyA resource-based authorization policy attached directly to a bucket. Simpler to use than RAM policies, and configurable through a graphical interface in the console. Bucket owners can configure policies through the console without needing RAM permissions. Supports cross-account access and anonymous access with IP address restrictions.Grant OSS permissions to RAM users or roles within your account, from other accounts, or to anonymous users. Also use when the bucket owner needs to manage access without RAM configuration.
    Bucket ACLAn access control list (ACL) applied at the bucket level. Only the bucket owner can set or modify it. Supported values: private, public-read, and public-read-write.Apply a uniform access level to all objects in a bucket. For fine-grained or maintainable access control, use RAM policies or bucket policies instead.
    Object ACLAn ACL applied at the object level. Set it at upload time or modify it afterward. Supported values: default (inherits the bucket ACL), private, public-read, and public-read-write.Override bucket-level permissions for individual objects — for example, making a specific object publicly readable while the bucket remains private. For broad or maintainable access control, use RAM policies or bucket policies instead.
    Block Public AccessOverrides all existing public access permissions granted through bucket policies and ACLs, and prevents new public access permissions from being created. Can be enabled at the global OSS level, per bucket, per access point, or per object FC access point.Close all public access channels when data security requires it — especially to prevent accidental exposure from misconfigured ACLs or bucket policies.
    Access pointA named endpoint for a bucket with its own access control permissions and network control policies. Create multiple access points for the same bucket to serve different clients or teams with different permission requirements.Manage access for large, shared datasets where different teams or application clients need different permissions to different folders in the same bucket.
    Hotlink protectionControls which domains or applications can link to your OSS resources by checking the Referer and User-Agent headers of HTTP requests. Configure allowed origins using whitelists, blacklists, or regular expressions.Prevent unauthorized websites from hotlinking your resources — suitable for audio and video playback, image hosting, and software downloads.
    Cross-origin resource sharing (CORS)Defines cross-origin access rules for a bucket, allowing browser-based scripts to access OSS resources from different origins. Configure allowed origins, HTTP methods, and request headers.Enable browser-based applications, H5 pages, or miniapps to make cross-origin requests to OSS — for example, direct uploads from a frontend or cross-origin loading of audio and video.

    Choose an access control method

    Use these guidelines to select the right method for your scenario:

    • Grant access to users within your Alibaba Cloud account — Use a RAM policy. RAM policies let you manage permissions centrally across multiple users, groups, and roles. This is the recommended starting point for most access control requirements.

    • Grant access to users from another Alibaba Cloud account, or to anonymous users — Use a bucket policy. Bucket policies support cross-account access and anonymous access with IP address restrictions directly on the bucket, without requiring RAM configuration in the other account.

    • Apply the same permission level to all objects in a bucket — Use a bucket ACL. For more selective or maintainable control, use a RAM policy or bucket policy instead.

    • Override permissions for individual objects — Use an object ACL. For example, set a bucket to private and mark one object as public-read. For broad access control, use RAM policies or bucket policies instead.

    • Prevent any public access regardless of other policies — Enable Block Public Access. This overrides all existing public ACLs and bucket policy public grants, including any that were previously set.

    • Give different application clients or internal teams isolated access to specific folders in one bucket — Create separate access points, each with its own permissions and network policies.

    • Prevent other websites from embedding or hotlinking your media files — Configure hotlink protection with a Referer whitelist or blacklist.

    • Allow browser-based uploads or cross-origin requests from your web app — Configure CORS rules on the bucket.

    If a bucket has multiple access control policies, such as RAM policies, ACLs, and bucket policies, see OSS authentication details for information about the authentication flow.