I am building a Web app, powered by react in frontend and Django in the backend.
It uses Django REST framework for providing raw data to react
But when it came to data transfer, I got scared.. I was told to use CORS headers and use a WHITELIST list to mention the allowed urls which can access the data.
Also, when I need to feed an entry in database, I need to make further allowances.
So is it safe to go like this?
I think one can easily steal data midway.
You would need to set up CORS only if your React and Django apps are on different domains/ports or use different protocols.
If that's the case, whitelisting the origin of the React app in Django is the proper (only) way to go. It's not specific to Django - that's a browser feature.
Actually, I would be worried if a backend framework accepts cross-origin requests without explicit set up.
I guess your current issue comes from node and django dev servers running on different ports. If that's true and both apps will be accessible on the same domain when deployed, you can just allow all cross-origin requests when DEBUG=True
Read more on the topic on MDN
Related
I have been reading around CSRF for the past few days and feel like I have a good grasp on what it is and how to prevent it. I am building a small Express/React application that will have a secure admin area for updating the app content and I want it to be protected from CSRF.
I understand that it is common for the server to generate the CSRF token and then send it to the client along with the view (page) that has been requested (the token can then be hidden in a HTML form input tag). However, my Express API does not serve HTML, it is a REST API that only returns JSON data. The UI is built with React, running on a different port from the server.
My question is; Where do I securely store a token generated on the server?
For example, if I log in as admin by hitting '/api/login', generate a token, and send it back to the client in the API response, what should I do with it now?
The original plan was to use Redux to store the token but from reading this post Is Redux secure?, this does not sound ideal.
I considered using React env variables but have also read that these are exposed in the build.
Obviously localStorage is also a bad idea...
I am really struggling to find a solution to this problem using the tools I am implementing i.e. Express/React
Any help, links, advice, criticisms would be appreciate, I want to learn to build apps with security in mind
I understand that it is common for the server to generate the CSRF token
The server needs to generate two CSRF tokens
and then send it to the client along with the view (page) that has been requested (the token can then be hidden in a HTML form input tag).
One token is commonly sent as a cookie, another can be sent as HTTP header. It doesn't need to be sent inside HTML body as a HTML form input tag (or any other part of the body) though it can be sent this way.
My question is; Where do I securely store a token generated on the server?
You don't have to store a token on the server. You can but you don't need to.
The original plan was to use Redux to store the token
The Redux store is on the client, in browser's memory. In theory one React component (that extracts the second CSRF token from server response) can temporarily store the token in the store so that another React component can get it from there and put into the next request before it's sent to the server.
Obviously localStorage is also a bad idea...
Yes
Any help, links, advice, criticisms would be appreciate, I want to learn to build apps with security in mind
Links
With Express is very common to use this middleware. The steps can be found here.
Criticisms
This is strictly speaking off topic in the context of CSRF related Q/A, but ...
The UI is built with React, running on a different port from the server.
That hints to the possibility of using react-scripts which start webpack-dev-server. It's fine for development, not good for deployment in production. However this is a separate topic, serving React app's build artifacts (.html file, script bundles) to webclients has nothing to do with CSRF attack and its mitigation.
I want to learn to build apps with security in mind
Then you might consider using one webserver instead of two (frontend to serve React app and backend to serve API responses). Using one server results in production deployment which is not only less complex and costly, but also more secure because two servers have larger attack surface and with one server you don't need to weaken security by using CORS.
I have been learning angular 2 and have been doing research on how to protect data within my app.
How, if possible, can you obstruct data from the front end of the app? Is it possible to serve the angular app through a node server, say using Universal Angular, which would mean variable values can be hidden from the user on the front end.
I am essentially looking for the solution of hiding private keys which will give the app access to various APIs/creating auth headers/paths. I've read a solution is to have an API bridge for the app - so I would connect to that to retrieve the data/keys - but then how do I protect that from access? Since that endpoint would then be exposed and could be abused, or if getting keys the response is visible. The idea of locking down to domain I have read is unreliable due to spoofing and locking to IP wouldn't work as its front end or through an app?
I feel there is a glaringly obvious answer that I am missing something.
You must assume that everything that is held in your frontend is visible to anybody that can access your frontend.
All JS variables, storage (local, session), network requests, etc. in your front end are unsecured from users of your frontend.
You can (and should) use SSL to make hide data from anybody in between your server and the browser, but there is just no way to secure data held in your frontend from users of your frontend. (At least if your frontend is available on "regular" browser as opposed to some tightened kiosk mode installations.)
It's simple, when the server sends the data as response to a request, then the data can be accessed from the outside.
If you don't want that, then don't send the data.
You didn't mention what problem you actually try to solve. For API keys you can for example do the request to the API on the server and provide an API on your own server for your clients and then make the server forward the requests to the actual API server.
I have a JSP webapp developed in Eclipse as a dynamic web project.
we use a third party web application that invokes my application, I need to validate that only the requests that come from that application are allowed to create a new session in my application.
I´m tring to do it with javascript and thinking , as a last resource, to use a Filter class to know the request origin and define the behaviour.
the problem is that the user requires that the operation is done on the client side, meaning I have to use javascript or similar, I have read about document.referrer on JS, but so far nothing is shown on the console.
Anything that you do in the client using JS for handling sessions wouldn't be secure as it can be easily modified by a malicious user. Also, using the referer or any other http header params would be insecure as they can also be easily spoofed.
If this third party application is directly calling your application I imagine that you have some degree of control over it. Can you access and modify its source code or are you just using configuration params?
Ideally the third party application would use an authentication token on each request that it makes to your application. And these authentication requests as well as all the session handling logic would always be handled on the server side.
I want to develop a front-end in Javascript (possibly with one of the fancy frameworks around such as AngularJS) that consumes the REST API of my Salesforce org.
I don't want to embed my project in Salesforce technologies, so basically
no Visualforce pages
no Force.com Sites
I do want to write my own front-end on a separate server that just makes AJAX calls to the Salesforce back-end.
In addition, I want the application to be accessible for any user, even if he/she does not have a Salesforce account. So the AJAX calls should not require that the user logs in on Salesforce. I want anonymous users to be able to retrieve public data from my organization and create new entries when it is useful (in the case of a survey for instance).
Even though these requirements generate some security concerns, I can imagine that Salesforce takes care about the requests rate limits on their API endpoints and that it is possible to restrict the access to the API on a host name base (e.g., only requests with origin host my-trusted-domain.com should be allowed, send a 403-Forbidden otherwise). I would be surprised if SF does not provide such basic features.
How would you proceed? Is there a minimal Javascript code that works out-of-the-box on any domain without getting into troubles with CORS?
All REST API calls to Salesforce must be authenticated. If you want anonymous API access then you will need to proxy authenticated calls through a server (like on Heroku) that adds the auth token. Or you can use Heroku Connect to expose your Salesforce data to a Heroku app as a Postrgres database.
If you go the REST route then checkout the ForceServer and my CORS Proxy for Salesforce. Both are not setup out-of-the-box for the anonymous access you are looking for but could easily be tweaked to support that use case.
BTW: When allowing anonymous access to your Salesforce data through a proxy make sure you are dealing correctly with security and request limits.
I am not familiar with this issue and I hope you can help.
I am developing a web application. My Backend api endpoints sits under http://www.example.com/api where my front end application located in http://www.otherdomain.com.
The problem is that I get cross domain problems when I am trying to make ajax requests.
I am using AngularJS in the frontend and RoR (rails) on the backend.
Do you have any idea how to fix it?
For security reasons browsers are blocking ajax request for another domain(you can read here). But you can try to use $http.jsonp()
We encountered this several times before in our PHP & Java Backend Api's. But our solution was always to include this to your api server header: Access-Control-Allow-Origin "*"
The best solution would probably be to set a reverse proxy using nginx so that the requests can be received by a local server, on your local domain, and reverse-proxied to the destination server exactly as they were received (CORS limitation do not apply on servers).
Another solution is this neat Javascript proxy:
https://github.com/jpillora/xdomain