When your Object Storage Service (OSS) buckets are attacked or experience fraudulent traffic, bandwidth or traffic spikes occur. This causes your storage fees to be unexpectedly higher than in normal cases. To prevent security risks and unexpected bills, we recommend that you use security best practices provided in this topic to protect your buckets.
The following best practices are general security measures, not complete security solutions. These best practices are provided only for reference and may not be suitable for your business scenarios. We recommend that you remain aware of data security threats and take the necessary precautions and preventative measures.
Unexpectedly high fees
Attacks and fraudulent traffic against buckets can cause the following financial consequences:
High bills: Extra OSS bandwidth and traffic is consumed, and you need to pay for the traffic resources consumed.
Negative account balance: If you use OSS on a pay-as-you-go basis, due to factors such as the billing cycle and delayed bill processing, the service is not suspended immediately when your account balance reaches zero. This causes a negative account balance. If your buckets are attacked or experience fraudulent traffic, bandwidth or traffic spikes occur. You are charged more than your Alibaba Cloud account balance.
Set the ACL of your buckets or objects to private
Do not set the access control list (ACL) of your buckets or objects to public-read or public-read-write unless your business requires all users, including anonymous users, to read data from and write data to your OSS resources. For example, if you set the ACL of a bucket to public-read or public-read-write, the following changes take effect:
Public-read-write: All users, including anonymous users, can read data from and write data to objects in the bucket.
WarningAll Internet users can access objects in the bucket and write data to the bucket. This may result in data leaks and unexpectedly high fees. If a user writes prohibited data or information to objects in the bucket, your legitimate interests and rights may be infringed. We recommend that you do not set the bucket ACL to public-read-write unless necessary.
Public-read: Only the bucket owner can write data to objects in the bucket. Other users, including anonymous users, can read data from objects in the bucket.
WarningAll Internet users can access objects in the bucket. This may result in data leaks and unexpectedly high fees. Exercise caution when you set the bucket ACL to public-read.
A bucket or object that allows public-read access or public-read-write access may lead to data breaches. Therefore, we recommend that you set the object ACL or bucket ACL to private. If you set the bucket ACL to private, only the bucket owner can read data from and write data to the objects in the bucket. Therefore, before you change the object ACL or bucket ACL to private, make sure that your business is not affected.
You can use multiple methods to set the object ACL or bucket ACL to private. For more information, see Bucket ACLs and Configure ACL for objects.
Configure CloudMonitor alert rules
You can create alert rules to monitor the usage and the status of OSS resources. When an alert rule is triggered, CloudMonitor sends an alert notification to you so that you can check and handle the exceptions at the earliest opportunity.
For example, you can configure an alert rule for a bucket to monitor resource usage, send you alerts by text message, email, and DingTalk when the specified usage threshold is reached, and write the alert information to the Logstore specified in Simple Log Service.
The following figure shows how to configure an alert rule that is triggered when the Internet inbound traffic is equal to or greater than 100 MB.
You can configure alert rules for a bucket or all OSS resources that belong to your Alibaba Cloud account. For more information about how to configure an alert rule, see Create an alert rule.
Configure hotlink protection
You can configure a Referer whitelist for a bucket to prevent unauthorized access to your resources in the bucket.
OSS determines the source from which a request is sent based on the value of Referer in the request. When a browser sends a request to the web server, Referer is included in the request headers to specify the source from which the request is sent. OSS determines whether to allow the request to a bucket based on the value of Referer in the request. If the value of Referer in the request is in the Referer whitelist that is configured for the bucket, the request is allowed. If the value of Referer in the request is not in the Referer whitelist or is in the Referer blacklist that is configured for the bucket, the request is denied.
The following figure shows a hotlink protection configuration which includes https://www.example.com in the Referer whitelist and denies requests with an empty Referer header.
After the preceding hotlink protection is configured, if an authorized user sends a request to upload the exampleobject.png image to https://www.example.com from a browser, https://www.example.com is included as the value of the Referer header and OSS allows the request from the browser.
If another user attempts to hotlink the exampleobject.png image to https://example.org, https://example.org is included as the value of the Referer header in the request for the image. Because the value does match with the Referer whitelist, OSS denies the request.
For more information, see Hotlink protection.
Configure CORS rules
Cross-origin resource sharing (CORS) is a standard cross-origin solution that is provided by HTML5 to allow web application servers to control cross-origin access. This ensures the security of data transmission across origins. Browsers use the same-origin policy mechanism to isolate potentially malicious data and deny cross-origin requests by default. For example, if the JavaScript code on one website makes a request for a resource hosted on another website that has a different origin, the browser denies the request.
OSS allows you to configure CORS rules to allow or deny cross-origin requests based on your business requirements. For example, you can use the CORS configurations shown in the following figure to allow HTTP GET requests from www.aliyun.com to your bucket.
For more information, see Configure CORS.
Avoid naming objects by sequential prefix
When you upload a large number of objects and name them by using sequential prefixes such as timestamps and letters, dates, and numeric IDs that can be traversed, attackers can figure out the name rules and create a script to obtain all objects. This causes data leakage. In this case, we recommend that you add hexadecimal hash prefixes to your object names or name objects by reversing the order of timestamp digits. This can reduce the risk that the object names are traversed. For more information, see OSS performance and scalability best practices.