By using AWS re:Post, you agree to the Terms of Use
/Protect and secure http API GW/

Protect and secure http API GW

0

Hi team,

I asked this question many times and each time a got an answer that doesn't match my scenario description :) .

Please Kindly read carefully the scenario :) :)

I have an HTTP API GW (not REST GW), I want to secure this GW by preventing users to bypass the CF and hitting it directly.

Since HTTP GW don't support WAF the scenario described here doesn't work for my case :

https://wellarchitectedlabs.com/security/300_labs/300_multilayered_api_security_with_cognito_and_waf/3_prevent_requests_from_accessing_api_directly/

because this assumes that :

1 - the Origin of the CF distribution is the API GW (but in my case my Origin is an S3 bucket)

2- the API GW support WAF to be able to read the rule and block request that doesn't have that specific header (but in my case my HTTP GW doesn't support WAF)

due to those 2 facts, I ended up that I can't use the solution proposed in the above article (because HTTP GW doesn't support WAF and thus cannot read the WAF rule to block the request that doesn't have the header injected by CloudFront).

please is there a solution to secure HTTP API GW and prevent hitting it directly?

users => CloudFront(with s3 bucket as Origin and WAF linked to it) => Http GW (not REST GW, NO WAF linked to it) => NLB => fargate cluster.

2 Answers
1

You mixed up to separate communications into one.

The communication is. Client gets content from S3 (S3 as CloudFront Origin), to prevent direct Access to S3 you must use the origin access identity https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

Then you have a second Communication Client ==> API Gateway. There is no direct communication as you described from S3 => API Gateway. You can also see this in the Developer Console of Firefox for example. To prevent direct API Gateway communication you have to define another Origin which points to the API endpoint (Client => CloudFront => API Gateway) and there you have to add the custom header. You are right, WAF will not prevent direct HTTP API requests, but you must use the custom Header and check the value in a custom Authorizer for your API Gateway https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html

To improve that even more you can rotate the secret automatically and let Lambda@Edge add the secret as header to the Request. So, as mentioned in the other answers. As long as this secret keeps secret your API can only be called via CloudFront.

answered 2 months ago
  • this is what i descripbed in my scenario :

    users => CloudFront(with s3 bucket as Origin and WAF linked to it) => Http GW (not REST GW, NO WAF linked to it) => NLB => fargate cluster.

    so yes no direct communication between s3 and API GW

    my whole point is to prevent users bypass CF and hitting directly API GW without using WAF, as HTTP GW doesn't support WAF

0
Accepted Answer

I understand from your question that you want to protect your APIs with WAF but as you use HTTP APIs, which does not support WAF, you enable it in CloudFront and you want to make sure that the requests arriving at Gateway are coming from CF and that nobody bypassed it and therefor bypassed WAF.

You must understand that CloudFront may have multiple origins: S3 for the static content of the page and API Gateway for the dynamic content (the API calls). The client hits CF which forwards some requests to S3 and forwards the API requests to API Gateway. Usually it is done by domain name or path, e.g., site.example.com will be forwarded to S3 and api.example.com will be forwarded to API GW.

To verify that the requests are coming from CF it needs to create a header with some secret value that is then verified by API Gateway. The link you mentioned shows how to do it in CF. As you mention HTTP API does not support WAF in order to verify the header, however, it does support Lambda authorizers. You can verify the value of the secret header in a Lambda authorizer.

EXPERT
answered 2 months 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