Security of AWS API Gateway

Question

I have the following url to invoke services behind API Gateway: https://< random-key >.execute-api..amazonaws.com/prod/..., so far I have not enabled API Key and authorization.

Question: Is it secure enough? sb. said it is not secure because anybody can use the url to invoke my services behinds the url, not only me. One solution is I can enable API key and attach the API key as request header when invoking the url. The other solution is to use AWS Cognito, etc.

Why is it not secure? isn't < random-key > a kind of credential already? Only I know this < random-key > and I give the api url with < random-key > only to the person I trust, nobody else knows what is < random-key > of the url. And if sb. really wants to spy the < random-key >, then attaching API key does not help because if the person can steal < random-key >, he can steal the API key as well.

I understand the API Gateway can also use AWS cognito for authentication. i.e. when a person access the url, he will be asked to input credential (user/password), but again, this credential can also be stolen, the same as how the < random-key > and API Key can be stolen.

IMO, using < random-key > and the API key and the credential are the same thing. so that is why I think I just need to set API Gateway as public without enable API Gateway and AWS cogonito.

Am I correct? Can anybody explain why having API Gateway or AWS cognito is more secure than without using them?

Another question related to the above question: since the url uses https, will the url itself (including < random-key > ) not be encrypted while the request header like API key, and the content like username/password be encrypted?

Answer 1

Security through obscurity is like burying your money under a tree. The only thing that makes it safe is no one knows it's there.

The most important security factor is always risk. We can never create a perfectly secure system, we can only ever try to balance the cost of attacking the system with the cost of it being breached. So before anything else, I'd ask: what is at risk if someone knew your API's URL?

You are right - it is a minimal form of security. Just nothing more than that.

Ask yourself a set of questions:

• What can an attacker learn by a response? - if you simply need to know something exists to start getting responses, you can start testing it to see how it behaves. You could thwart this by throttling ALL responses, but that might negatively impact your legitimate customers, so you ask...

• Can I limit what an attacker can learn by a response? - if the attacker needs more information to construct a legitimate request, you can throttle and constrain all non-legitimate requests.

And the questions continue to escalate from there. It all comes down to ROI - what is the value of what you're protecting, what is the attack surface area, and what is the risk of it being breached? The most important thing of all is your customers' and users' trust. As professionals we must protect the integrity of the information with which we are entrusted.

A separate question is under HTTPS (TLS/SSL) what is protected and what is not, from third party listeners? The short answer is if you request foo.com/bar, the hostname (foo.com) is visible to anyone that wants to know, but the path (/bar) is not; and cookies, headers, and anything else included in the request is secure.