I have a SPA website that is hosted in AWS s3 and served by cloudfront
There are multiple CNAMES that connects to this website, e.g. A.Mysite.com, B.Mysite.com
I have an API that the static website connects to that only want to serve content for A if the request comes from A.Mysite.com and B if the request comes from B.Mysite.com
Where should I store the API key? I'm guessing it's a bad idea to expose API key on the client side right?
I've looked through OAuth, JWT tokens etc. it seems like no matter what way, I still have to send a Access Key to the client side if I don't have a server...
Please help me understand this, since i'm very confused on how security between a static site and API can be achieved without a server.
Have you looked into Environment variables?
https://www.twilio.com/blog/2017/08/working-with-environment-variables-in-node-js.html
https://hackernoon.com/how-to-use-environment-variables-keep-your-secret-keys-safe-secure-8b1a7877d69c
Related
How can I protect an API request sent from a static site hosted on a CDN?
Use case:
A single page application using react is hosted on S3 + Cloudfront. The site calls the Yahoo Finance API to request some market data. The third-party API uses an API key to authenticate the requests. I can only store the third party API key in the static site making it available for anyone.
Considerations:
The static site and the API are not in the same cloud provider or service, so a solution using roles wouldn't work.
A Lambda (Function) proxy solution is my best choice at the moment IMO but this would still allow a request to be sent directly to the Lambda (Function).
The request to the function should also be secure, making the above option still vulnerable. This means that getting the URL to the Proxy Function from the source code and calling the Function is not acceptable either.
Looked around at some other questions posted but I haven't found one that addresses the particular circumstances stated here.
We received this google warning because one of our google projects has multiple domains.
Your project: {app} has multiple unique domains in the redirect URI and origin URLs, many of which have unrelated applications. This is in direct violation of the Google API Services: User Data Policy, which requires that projects accurately represent their identity and intent to Google and to our users when they request access to Google user data.
The first domain is the website of the app {app}.tld
The second domain is the api where OAuth happens {tenant-id}.subdomain.domain.tld
Our violation comes from the domain {tenant-id}.subdomain.domain.tld which is where we host our multi-tenant api.
Is it possible to resolve this issue while still using our multi-tenant api to handle the OAuth dance?
I Guess you are using the {tenant-id}.subdomain.domain.tld as the callback url and adding a unique url for each tenant.
To solve this issue i think you may add a single callback url. Something like callback.domain.tld may work. This endpoint should redirect the original google redirection to {tenant-id}.subdomain.domain.tld with all the query params from google. You can encode the tid in state so that you can decode it to redirect the request properly in the redirection service.
You can also use some services like AWS lambda to act as the middleman and redirect to your final endpoint.
It's okay with that {tenant-id}.subdomain.domain.tld as the callback URL and adding a unique URL for each tenant.
I have hosted a S3 static site into CloudFront. That site using rest api deployed into api gateway. API gateway has not access control.
I want to protect my api from being accessed by others. Only my static site can access it. I know I can use api key but that could expose by browser console which is not expected.
Is there other way to control my api access?
Thanks in advance
I have a similar issue as well. It seems like using referer or CORS restrictions are the best way to go. However, in practice I haven't been able to make it work after trying both CORS and referer restrictions. API Gateway has automatic protection against malicious behavior like DDOS attacks according to their FAQs, but it is disheartening that I haven't found a specific solution for protecting my API gateway that is only used for my S3/Cloudfront static site.
Google Cloud allows you to use their API keys on the frontend for integrations with services like Google Maps. The way they protect those keys is through restricting the API keys to certain domains. Unfortunately, I haven't found similar functionality for AWS keys. As you know, the only way to throttle or put quotas on API gateway is through API keys, so it looks like this would be useless for a static site that can't expose those API keys publicly on the frontend.
It defeats the whole purpose of going completely serverless if I am unable to configure my serverless API Gateway the same way I could congfigure a normal backend EC2 server. For now, I've created billing alarms so I don't get surprised with a huge AWS bill if something goes wrong with my unprotected API gateway.
I want to build an app with the following architecture:
The frontend would be deployed on shinyapps.io and would make call to an API written with plumber to interact with data.
The app would be private so a user would have to authenticate with the shinyapps.io auth module. The API would be hosted on a cloud platform.
I would like to know if it is safe to authenticate calls to the API by adding a secret key to the header on all HTTP requests.
The secret key would be defined in a .Renviron file deployed on Shinyapps.io and also on the API server.
This plumber filter should ensure that the secret key from the front and from the API match before sending the appropriate response.
Define safe? It is going to work for sure. If it is exposed to the public web, assume nothing is safe.
The filter you mentionned is there specifically for this use case. But it is still not safe against DDOS attacks.
Good luck.
Hello and thanks for looking.
Background
I am designing an application that will host certain pieces of information/data for third-party websites via an API and must be accessed via authenticated requests.
Is OAuth the way to go about this or is there something better out there? I will not know the domains of the third-party sites up front so I can not rely on host-headers (which can be spoofed anyway).
Requests to the API will most likely originate in jQuery or regular JavaScript on the client side.
Question
What is the best way to ensure that third-party websites requesting data from my API are who they say they are, and are allowed to access the information they are requesting?
Many thanks!
Matt
OAuth, particularly OAuth 2 (which isn't yet finalized), will likely work well for you. But since the web requests are coming from the browser rather than the web server hosting these web sites, each individual browser will have to be authorized rather than each domain.
So let's step back and ask this question:
Is the data your API will be exposing unique per individual user or unique per web site domain? Or in other words, are you as the API owner going to contractually authorize domains to access your data, or will individual users have data accessible via your API, and those users need to authorize these other domains to access to their own data on your service?
If you're authorizing domains (and not users) then the browser simply cannot be the initiator of these authorized requests to your API. This is because the web server on those domains would have to issue their secret key to the client, at which point they've lost control of it and anyone can make these authorized calls -- not just the domains you've intended to authorize. This is the "you can't trust the client" principle in security.
If you're authorizing users, then each user who visits one of these 3rd party sites will have to go through a one-time setup where the web site redirects their browser to your service to log in and say "yes, [3rd party site] can access my data", after which they're redirected back to that site. After that, any time they visit that site, the site can download a secret key that's unique to that user and can be used from javascript on the client to make these authorized API calls.