In mobile and Web applications, you can directly initiate requests to COS from your frontend through the SDK for iOS, Android, or JavaScript. In this way, data uploads and downloads do not pass through your backend server, which reduces its bandwidth usage and load and makes full use of various COS capabilities, such as bandwidth and global acceleration, to improve the user experience of your application.
In practice, you need to use a temporary key as the signature for a frontend COS request to avoid problems such as leakage of your permanent key and unauthorized access. However, even with a temporary signature, if you specify excessive permissions or paths, such problems may still occur, which brings certain risks to your application. This document describes some bad examples and security regulations that you need to comply with for your application to securely use COS.
This document assumes that you have a good understanding of the concepts related to temporary key, and can generate and use one to send requests to COS. For more information, please see Generating and Using Temporary Keys.
Application A uses COS when registered users upload profile photos. Each user has a fixed object key app/avatar/<Username>.jpg
for their profile photo, and another two object keys app/avatar/<Username>_m.jpg
and app/avatar/<Username>_s.jpg
for different photo sizes. When you generate a temporary key on the backend, you specify the resource
as qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/*
for convenience. In this case, when a malicious user gets the generated temporary key through methods such as packet capture, they may gain unauthorized access by uploading an image to overwrite any user's profile photo.
resource
indicates the resource path that a temporary key can access, and end users covered by this path need to be taken into full account. In principle, the specified resource
should be used only by a single user. In this example, the specified qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/*
will apparently cover all users, resulting in security vulnerabilities.
In this example, the path to user's profile photo can be modified to app/avatar/<Username>/<size>.jpg
, and resource
can be specified as qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>/*
to meet the security regulations. In addition, multiple values can be passed in to the resource
field as an array. Therefore, you can explicitly specify multiple resource
values to fully limit the final resource paths that users can access; for example:
"resource": [
"qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>.jpg",
"qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>_m.jpg",
"qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>_s.jpg"
]
Application B provides a public photo wall feature, and stores all photos in app/photos/*
on COS. To use this feature, the client needs to GET Bucket and GET Object. When you generate a temporary key on the backend, you specify action
as name/cos:*
for convenience. In this case, a malicious user may get the generated temporary key through methods such as packet capture to gain unauthorized access to all object operations (such as upload and deletion) on any object under the resource path, which causes data loss and affects your online business.
action
specifies the operations you can request using a temporary key. In principle, it is not allowed to specify name/cos:*
in the action
element so as to use the temporary key for access to all operations. Instead, you must explicitly list each one of them. Besides, if different operations require different resource paths, you should match the action and resource separately instead of combining actions for one resource or resources for one action.
In this example, you should specify "action": [ "name/cos:GetBucket", "name/cos:GetObject" ]
. For directions on granting operation permission, see Working with COS API Access Policies.
Application C provides a management tool that allows a user to list and download all users' files (app/files/), but only upload and delete files in their personal directory (app/files/
For multiple action
and resource
values, you should not simply concatenate them. Instead, use multiple statements to match an action with a resource to avoid granting excessive permissions.
In this example, you should use the following code:
"statement": [
{
"effect": "allow",
"action": [
"name/cos:GetBucket",
"name/cos:GetObject"
],
"resource": "qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/files/*"
},
{
"effect": "allow",
"action": [
"name/cos:PutObject",
"name/cos:DeleteObject"
],
"resource": "qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/files/<Username>/*"
}
]
Application D provides a forum service whose attachments to posts are stored in COS. This forum has different user levels. Only active users with a certain number of posts can view posts and attachments in certain sections, while some public sections are open to all.
The backend API generates temporary keys for downloading attachments in a certain section based on the section ID received from your frontend. However, in fact, the backend API cannot determine whether a requester has access to the specified section ID due to lack of proper logic. As a result, anyone can request this API for a temporary key and gain unauthorized access to attachments in a private section, leading to potential data leakage.
For your API that generates temporary keys, you should make sure that the temporary keys grant permissions as expected, and only to the correct requesters as needed in order to avoid unauthorized access by users with lower permission.
In this example, your API should also be able to determine whether the requester has access to a specific forum section, and deny the request if it determines not.
The examples above illustrate the security risks that may occur if permissions of a temporary key are more excessive than expected. In these cases, malicious users can get a temporary key more easily than when accessing COS through the backend, so you need to tighten your permission control.
The security regulations mentioned in this document are based on the minimum permission principle. In practice, you can enumerate all possible scenarios based on the action
and resource
. For example, 3 action values and 2 resource values can result in 3 * 2 = 6 application scenarios. You can evaluate whether the permissions are granted as expected based on this enumeration; and if not, you should consider using multiple statements to specify permissions.
You are also supposed to take authentication seriously for the temporary key generation API. Every precaution must be taken to protect your temporary keys.
Was this page helpful?