Never hard-code credentials to your web application unless the credentials are scoped to an IAM user with read-only permissions to very specific resources. Remember that when developing a client-side application in the browser, all source code you write is downloaded and available to be inspected by your users, so you should never put secrets inside of your application.
Credentials are the most important thing you need to set when using any AWS SDK. Credentials can be set globally on the `AWS.config` object or per service by passing the credential information to the service object directly. There are a couple of ways to load credentials. Here they are, in order of recommendation: 1. Using web identity federation to authenticate users 2. Hard-coded in your application We recommend you not hard-code your AWS credentials in your application; however, it is reasonable to temporarily hard-code credential information in small personal scripts or for testing purposes. It is also sometimes necessary to hard-code **read-only** credentials in your application. #### Using Web Identity Federation to Authenticate Users The recommended way to authorize users of your application to access AWS resources is to set up federated login through a trusted third-party identity provider. This feature is known as Web Identity Federation. Amazon Web Services currently supports authenticating users using web identity federation through 3 identity providers: 1. [Login with Amazon](http://login.amazon.com/) 2. [Facebook](https://www.facebook.com/about/login/) 3. [Google](https://developers.google.com/+/) After you select an identity provider, you must register an application with the provider, create an IAM role, and setup permissions for this role. The IAM role you create will be used to grant the permissions you configured to the users that login through the respective identity provider. For example, you can setup a role that allows users who login through Facebook to get read access to a specific S3 bucket that you control. Once you have an IAM role with configured privileges and an application registered with your identity provider of choice, you can setup the SDK to get credentials for this role using the following credential management helper code: ```javascript AWS.config.credentials = new AWS.WebIdentityCredentials({ RoleArn: 'arn:aws:iam::If you hard-code credentials in your application, ensure that the credentials you are vending in your application are scoped to an IAM user with read-only permissions to very specific resources. Remember that when hard-coding credentials in your application, you are allowing all of your users access to the secret key in plain text.
You can hard-code credentials by passing the credential information to the configuration object using `AWS.config.update()`: ```javascript AWS.config.update({accessKeyId: 'akid', secretAccessKey: 'secret'}); ``` ### Setting the Region The AWS SDK for JavaScript doesn't select the region by default. You can choose a region by setting the `region` property on the global configuration object, or by setting it per-service. The following code sets the region globally for all subsequent service objects: ```javascript AWS.config.region = 'us-west-1'; ``` ## Service-Specific Configuration Occasionally, you might want to apply configuration only to one service. For instance, you want to use multiple EC2 objects in different regions. You can do this by passing configuration data directly to the service object constructor: ```javascript var s3 = new AWS.S3({region: 'ap-southeast-2', maxRetries: 15}); ``` Note that the constructor takes all of the same configuration data as the `AWS.config` object described above, including credential information. ## Cross-Origin Resource Sharing (CORS) Cross-Origin Resource Sharing, or CORS, is a security feature of modern web browsers that allow them to negotiate which domains they will allow to make requests against which external websites or services. This is an important feature to keep in mind when developing applications with the AWS SDK for JavaScript in the browser, since most requests to resources will be sent to an external domain (the endpoint for the given AWS service). If your browser or environment enforces CORS security, you will need to configure CORS with the service. Fortunately, only Amazon S3 requires explicit configuration for CORS. Other services only require that the request is signed using authentication keys that have permissions on the resource (discussed above). ### Configuring CORS for an Amazon S3 Bucket In order to configure an Amazon S3 bucket to use CORS, you can visit the [Amazon S3 console](https://console.aws.amazon.com/s3), click on the properties tab of the bucket you want to configure, and then click "Edit CORS Configuration" in the Permissions section. A set of [sample configurations](http://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html#how-do-i-enable-cors) are provided in the S3 documentation. A quick CORS configuration sample is shown below. This sample allows a user to view, add, remove, or update objects inside of a bucket from any external domain, though it is recommended that you scope the "AllowedOrigin" to the domain that your website runs from (you can specify "*" to allow any origin).