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.

Notice The following best practices are a set of general rules, not a compressive set of security solutions. These best practices are for reference only and may not be applicable to your business scenarios. We recommend that you remain aware of data security threats and take the necessary precautions and preventative measures.

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.

You can use multiple methods to set the ACL of a bucket or an object to private. For more information, see Configure the ACL feature for a bucket and Configure ACL for objects.

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.

The following figure shows how to configure an alert rule that is triggered when Internet inbound traffic is equal to or greater than 100 MB.notification1

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.

For example, in the following figure, the Referer whitelist is set to https://www.example.com, and empty Referer is not allowed. referer

After you configure the Referer, assume that User A adds an image object named exampleobject.png to the 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 Referer whitelist.

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.

Configure CORS

Cross-origin resource sharing (CORS) is a standard cross-origin solution provided by HTML5 to allow web application servers to control cross-origin access. This way, the security of data transmission across origins is ensured. Browsers check cross-origin requests based on the same-origin policy to keep the website content secure. When a request is sent from Website A by using JavaScript to access Website B of another origin, the browser rejects the request. In this case, you can configure CORS rules to allow cross-origin requests.

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 GET:

cors

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.