API Gateway integration with S3

0

I've created a serverless application in AWS using API Gateway and more serverless components of AWS. My frontend is served by S3 static website hosting. This website includes a JS file that has one function to send an HTTP request to the API Gateway that triggers the lambda function. As for security requirements I must deny all traffic to the API Gateway that does not coming from the S3 website. Right now I am able to trigger the API stage from both my local terminal and the website. API Key still won't solve my problem because the user can add the required header and still access the API. VPC endpoint won't help in that case because the HTTP request is made through the user's browser and not the S3 bucket itself .

2 Answers
0

If you use TLS/HTTPS, then you could consider using the "Referer" header and reject requests that do not come from your S3 domain. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer

HTTPS headers are not a security feature, so your security team may still reject it.

Other options include using an identity on the site. AWS Cognito would work, but you could also implement a corporate SSO if you have one for external users.

profile pictureAWS
answered 17 days ago
0

As you say, the API request doesn't come from S3 - it comes from where the JavaScript is running which will be the user's browser. And because the user's browser is effectively the user themselves there's no practical way to stop the user (if they are technically aware enough) to dig through whatever security mechanism you put in place, find the appropriate keys/headers/whatever and call the API themselves.

As Rodney has said: If you have some sort of authentication that is integrated with your website and with API Gateway (perhaps using Cognito or a Lambda Authoriser) then only authenticated users will be able to call the API. That's still not perfect but it restricts access and also gives you the ability to see who is doing what with the API.

You might also consider using short-lived tokens (again, coupled with an authorizer on the API) but that still won't solve the underlying problem - that the user can still use those tokens for whatever the lifetime is; and they can renew them - because the website can do the same thing.

profile pictureAWS
EXPERT
answered 17 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions