I came across this issue when consider the fact that my react-application needs API keys to access a backend it is using for CRUD operations on a secured database:
https://create-react-app.dev/docs/adding-custom-environment-variables/
WARNING: Do not store any secrets (such as private API keys) in your React app!
I want users authenticated into the application to be able to perform these operations without necessarily having the API keys exposed to the end user.
Common consensus seems to be create a mid layer, ie an express server that handles enriching/forwarding the request properly. But at that point, the same issue occurs if I want to authenticate the web app against the midlayer, ending up one way or another exposing the original secured API backend.
Is there a way to guarantee a "handshake" between the front end application and the original secured backend? If I need access to the code base to do so, can I do so via a mid layer instead
You have to disable the CORS in your express server.Thats means except your front end, no other client can send request to your Express server. And then, though your authorizationfor your express server is exposed but its not gonna help unless the request is from your front end app.
Related
I have taken a look around the internet and all the solutions emphasize using Express and Node Js API in place to able to send an email. I would love to see any suggestions on how to best go about it because I don't have a backend in place. Thank you.
You're going to need some sort of backend otherwise the API-Key will be exposed.
From the SendGrid documentation:
When you have a browser-only application that reaches out to APIs, the API key has to be embedded in the application. Anyone with access to a browser-only application can access all of the Javascript source code, including your API keys.
Making your API key publicly accessible could result in anyone authenticating API calls with your API key — this is a significant security concern both for you and SendGrid.
You could use a serverless AWS lambda function or google function which would be a "backend" but without having to support the infrastructure / use a big framework.
If you have a web application with a (react) frontend communicating with a REST API, what is the best way to limit access to the views?
Let's say youre not creating a single page app, you have multiple server side routes all delivering a react frontend. These routes should all be protected via authentication, so basically even the (non sensitive) react frontend shouldnt be delivered to the client. Do you handle this on the frontend on every page? Or does that mean that i might be using the wrong tool? If you do a server side session login you would have to handle the authentication and thus especially the entity layer in two spots (limiting access to views and API). I guess you can propagate the web server login to the API or vice versa, but i'm really unsure of what is the best way to go here.
I really hope the question is not going to be viewed as "subjective".
The following is the architecture of my Web application.
Web UI(Angular JS) running on nginx
Back-end data access layer (Java App) running on glassfish app server
My question is, how can I prevent a valid user from tampering or manipulating the REST service JSON request using some proxy tool.
One thing that I thought of was to encrypt the JSON but this will still expose the public key and the source code of how to encrypt it since its done on client side scripting. Is there a better way of doing secured JSON request?
P.S: I'm not talking about "Man in the middle Attack". This is not related to session hijacking. This is about a valid session user tampering the POST request using tampering tools.
You can't.
Anything that runs on client-side is exposed. Almost everything there can be tampered.
So your best bet is that you have a strong server-side validation before you process the data from the client.
I'm currently developing a ReactJS & Firebase app, but I'm facing the following problem:
As all the code is run in the client side, how can I connect to the payment API without exposing my private token?
I was thinking on creating a Google Cloud Function that could handle this requests. I think this functions should manage maybe a sign in to get the token, and later request the payments. Should this work?
Right now Google Cloud Functions isn't free to make requests out of a Google app. Does someone know how could I avoid the $25/month?
Another alternative I was thinking on was creating a Rails API on Heroku to manage only this requests, but I'm not sure if I'm not exposing the tokens by managing the logic on the front side. (Because the front end would have to talk to Firebase and this new API)
Security is a must.
Thanks!
I'm new to both angular and web api, I've worked previously on asp.net web forms and java jsp's my question is since angular is pure js framework and web api is used for Http services ,if we build web applications using both these technologies how can session management be handled, can we create session in web api controllers ? If we can, since webapi (REST) is stateless does it violate the principle of REST statelessness , please clarify
Thanks
Angular and WebAPI do not change how to track session in web applications. Usually, this is done with a cookie that is sent with every request. Since cookies follow domains, Angular requests will always send in the cookie (just like they did before).
To answer each of your questions:
can we create session in web api controllers?
Yes, we can access session through HttpContext.Current.Session.
does it violate the principle of REST statelessness?
REST (Representational State Transfer) doesn't have a principle of statelessness. HTTP is a stateless protocol. REST says that calls to the server (using HTTP verbs etc.) should progress state of the application.
I don't have the reputation to comment in response to him yet, but David Tyron seems to be misunderstanding the term "stateless" in this context. Obviously, both the API and the UI using it have to maintain and progress data that can be properly labeled a state, but in the context of RESTful APIs, "stateless" is usually specifically referring to the fact that the API doesn't keep track of the client's state.
The idea behind this is that each request to the API must include all of the necessary UI information to perform the required action. In other words, each call must happen in isolation and independent from each other.
Sessions absolutely violate this principle, though it's probably the most common thing that is used that prevents something from being 100% RESTful.
(On a related note, Cookies still count as stateless since the client is the one responsible for storing that data.)