Avoiding Financial Losses or Resource Drain Due to Malicious Access

Configuring Block Public Access (BPA)

In public access, a requester can access a bucket and data in the bucket without specific permissions or identity authentication. This increases the risks of data leakage and Internet malicious access. To avoid these risks, bucket owners can configure BPA to restrict public access to resources. With this feature enabled, existing public access permissions are ignored and new public access permissions cannot be granted.

For more information, see Block Public Access.

Changing an ACL to Private Access

Unless you want to grant anonymous users the read and write access to your OBS resources, do not set the ACL of a bucket or an object to public-read-write or public-read. These two types of public permissions are described as follows:

• public-read-write: Anyone (including anonymous users) has read and write access to objects in a bucket. This may cause data leakage and increase costs due to a large number of write operations. Moreover, the legal risks increase because illegal information may be maliciously written to your bucket. Therefore, you are not advised to configure public-read-write unless in special scenarios.
• public-read: Only the bucket owner can write to the bucket. Anyone (including anonymous users) can read the data, which may cause data leakage and surges in cost.

Given the data security risks from the above two types of permissions, you are advised to set the ACL of a bucket or object to private access. In this way, only the bucket or object owner has read and write access to the related resources. Before changing the ACL to private access, ensure that your services will not be affected by the change. For details, see ACLs.

Monitoring Malicious IP Addresses Using Bucket Logs

You can enable bucket logging and monitor the Remote IP field in bucket logs. This field is used to record the IP addresses that initiate access requests. You can flexibly use this field to protect the bucket in the following ways:

• You can use the Remote IP field to identify access attempts from unknown or suspicious IP addresses and detect potential malicious attacks, such as brute-force attacks and data theft. If an IP address frequently initiates abnormal access requests, you can take corresponding security measures, for example, restrict the permissions granted to that IP address.
• You can use the Remote IP field to observe the traffic usage of different IP addresses or IP address segments. If abnormal traffic peaks are detected, you can take corresponding security measures in a timely manner to cope with possible network congestion or DDoS attacks.
• You can periodically review the historical records of the Remote IP field in bucket logs to find out abnormal access patterns or potential security threats that have not been detected for a long time. For example, if an IP address has abnormal behavior in a past period of time, you can detect it through historical record review and take measures in a timely manner.

For details, see Bucket Logging.

Configuring URL Validation

In HTTP, the Referer field indicates web pages as the request source. URL validation of OBS utilizes this field to help you detect any sources that are not allowed and block the requests from those sources or redirect the requests to a specific web page. URL validation checks whether a request source is allowed based on the configured whitelist or blacklist. Only sources whose Referer fields are on the whitelist can make successful requests. This prevents the websites other than your own from stealing your files and avoids extra traffic charges.

Assume a whitelisted referer for a bucket is https://11.11.11.11.

• User A embeds the image test.jpg into https://11.11.11.11. When the browser requests the image, https://11.11.11.11 is carried for the Referer field. In this scenario, OBS allows the request.
• User B hotlinks the image test.jpg and embeds it into https://22.22.22.22. When the browser requests the image, https://22.22.22.22 is carried for the Referer field. In this scenario, OBS rejects the request.

For details, see URL Validation.

Configuring Cross-Origin Resource Sharing (CORS)

CORS is a mechanism defined by the World Wide Web Consortium (W3C) that allows a web application program in one domain to access resources located in another one. For normal web page requests, website scripts and contents in one domain cannot interact with those in another because of Same Origin Policies (SOPs). OBS allows you to flexibly configure CORS rules based on your service scenarios to allow or reject cross-origin requests, ensuring the security of cross-origin data transmission.

For details, see Configuring CORS to Enable Cross-Origin Access to OBS.

Avoiding Using Sequential Prefixes to Name Files

If you name objects in a way that is easy to find a pattern from, for example, by timestamp, alphabetical order, date, or numeric ID, attackers can obtain files in batches based on the naming pattern, resulting in data leakage. To avoid this problem, you are advised to use a more secure naming method, for example, adding a hexadecimal hash value before a file name. With this method, the randomly generated character sequence is difficult to predict, which reduces the risk of malicious traversal of file names and further reduces the risk of malicious access.