When your Object Storage Service (OSS) buckets suffer attacks or fraudulent traffic, sudden spikes in traffic occur. This causes your storage fees to be unexpectedly higher than your regular storage costs. To address this issue, we recommend that you implement the following security best practices for data security and protection.
Block public access
Do not set the access control list (ACL) of the buckets or the objects to public read or public read/write unless your business requires all users, including anonymous users, to be able to read data from and write data to your OSS resources. Description of public read/write and public read:
- Public read/write: All users, including anonymous users, can perform read and write
operations on objects in the bucket.
Warning All users can access objects in the bucket and write data to the bucket. If you set the ACL to public read/write, unexpected access to objects can cause unexpectedly high fees. Therefore, we recommend that you do not set your bucket ACL to public read/write except in special cases.
- Public read: Only the bucket owner can perform write operations on the objects in
the bucket. Other users, including anonymous users, can perform only read operations
on the objects in the bucket.
Warning All Internet users can access objects in the bucket. This may result in unexpected access to the data in your bucket and unexpectedly high costs. Exercise caution when you set your bucket ACL to public read.
To reduce security risks caused by public access, we recommend that you set the ACL of a bucket or an object to private. After you set the ACL to private, only the bucket owner can read and write the bucket and the objects in the bucket.
Configure alert rules in the Cloud Monitor console
You can create alert rules to monitor the usage and the status of cloud service resources. When an alert rule is triggered, CloudMonitor sends an alert notification to you. This way, you can be informed of exceptions and handle them efficiently.
For example, you can configure an alert rule for a bucket to send you a notification by using Short Message Service (SMS), email, and DingTalk and write the alert information to the Logstore specified by using Log Service when the Internet inbound traffic, Internet outbound traffic, CDN inbound traffic, or CDN outbound traffic is equal to or greater than 100 MB.
You can configure alert rules for a bucket, and you can also configure alert rules for all OSS resources owned by your Alibaba Cloud account. For more information about how to configure alert rules, see Create a threshold-triggered alert rule.
Configure hotlink protection
You can configure a Referer whitelist for a bucket to prevent your resources in the bucket from unauthorized access.
OSS determines the source from which a request is sent based on the Referer header field in the request. When a browser sends a request to the web server, the Referer field is contained in the request to indicate the source from which the request is sent. OSS determines whether to allow or deny the request based on the Referer field contained in the request and the Referer whitelist configured for the specified bucket. If the Referer field in the request matches the Referer whitelist, the request is allowed. Otherwise, the request is denied.
https://www.example.com, and empty Referer is not allowed.
After you configure the Referer, assume that User A adds an image object named exampleobject.png
https://www.example.com website. When a user accesses the image on the website, the browser sends a request
in which the value of the Referer field is
https://www.example.com. OSS allows the request because the Referer field in the request is included in the
User B adds the URL of the image object to the
https://example.org website without authorization. When a user accesses the image on the website, the
browser sends a request in which the value of the Referer field is
https://example.org. OSS denies the request because the Referer field in the request is not included
in the Referer whitelist.
For more information about hotlink protection, see Hotlink protection in Developer Guide.
OSS allows you to configure CORS rules to allow or deny cross-origin requests based
on your requirements. For example, the following figure shows the CORS rule configuration
if you want to allow only requests whose source is
www.aliyun.com and whose cross-origin request method is
For more information about CORS, see Configure CORS rules.
Do not name objects by using sequential prefixes
When you upload a large number of objects and name them by using sequential prefixes such as timestamps and letters, dates, numeric IDs that can be traversed, attackers can figure out the name rules and create a script to obtain all the objects. This causes data leakage. Therefore, we recommend that you add hexadecimal hash prefixes to your objects or name the objects by reversing the order of digits that indicate seconds in object names. This can reduce the risk that the object names are traversed. For more information, see OSS performance and scalability best practices.