I use an Express backend with the nuxt.render middleware to consolidate my API, front-end and development environment. So far, everything is going great, but I had some concerns about security concerning my auth setup.
My backend injects its user session into Vuex through a Nuxt middleware. While this works great for restricting access, the source code of those files is always available with a direct GET method. (e.g. if /admin is protected, /_nuxt/admin.js will still be available and will contain the entire source code of that page). Worst even, because of the default preload links put in the head by Nuxt, they will be automatically fetched, even if not logged in.
I understand that there are not a lot of security concerns with this because my admin API calls enforce the auth on the server side, but sometimes (as it is my case), exposing the source code is not desirable.
I have come up with a solution that works great, while being not very elegant:
In nuxt.config.js, I set render.resourceHints = false. I wish I didn't have to do this to benefit from the prefetching of available routes, but there seem to be no way to restrict the selection of prefetched routes.
Before plugging next.render into the Express' middleware chain, I selectively restrict the page's source code. (e.g. app.get('/_nuxt/pages/admin.js', restrict), where restrict is a middleware that returns a 401 if not authenticated, or calls next() if it is. That prevents both XHR fetching and direct GET.)
I make a custom error.vue template, where I catch the error message Nuxt will throw if forced to access a route that the user shouldn't have access to, which looks like Loading chunk 1 failed, and normalize it to a "Forbidden" error page.
Is there a more pragmatic way of doing this that I miss, or is that outside the scope of what Nuxt.js provides at the moment?
Related
So I have few things to say I don't want to use cookies so things like express-session doesn't come as option.
I use nodejs with express with no front-end JavaScript and mysql as database. I don't really know how to do it so I would like to hear your opinion.
I already tried to search on internet.
When dealing with regular web pages, there are only four places in a request to store information that would identify a session.
Cookie sent with each request
Custom header on each request
Query parameter with each request
In the path of the URL
You've ruled out the cookie.
The custom header could work for programmatic requests and is regularly used by Javascript code with various types of tokens. But, if you need a web browser to maintain or send the session on its own, then custom headers are out too.
That leaves query parameters or in the path of the URL. These both have the same issues. You would create a sessionID and then attach something like ?sessionID=92347987 to every single request that your web page makes to your server. There are some server-side frameworks that do sessions this way (most have been retired in favor of cookies). This has all sorts of issues (which is why it isn't used very often any more). Here are some of the downsides:
You have to dynamically generate every single link in a web page so that it will include the right sessionID as part of the link so if the user clicks on it, the resulting http request will have the right sessionID included.
All browser caching has to be disabled or bypassed because you don't want the browser to use cached web pages that might contain the wrong sessionID.
User bookmarks basically don't work because they end up bookmarking a URL with a sessionID in it that won't last forever.
The user sees sessionID=xxxx in all their URLs.
Network infrastructure that log the URLs of requests will include the sessionID (because it's in the URL). This is considered a security risk.
All that said and with those tradeoffs, it can be made to work, but it is not considered the "safest" way to do it.
I have a Vue Storefront which, out of the box, exists of a Nuxt.js front-end and a Express.js back-end.
In this project I created a custom Server Middleware (which is the Express.js part) that has an Axios call in it. My entire Vue Storefront project is hosted and deployed on a server where I also store the secret keys for the Axios call as eviorment variables. Whenever I request data via the Axios call on the deployed website, I can still see my secret keys in payload in the browser console.
Can these keys be hidden? Since the call is done in the VSF Server Middleware (which is a Express.js server under the hood) and my secret keys are defined on the server too... Not in a .ENV file.
The official docs also state the following about the server middleware:
Securely store credentials on the server without exposing them to
theend-users of your application,
I also have Server Side Rendering enabled, if this has any effect on this.
As explained in my previous answer here, you cannot really hide anything on a client side app.
The fact that you do have ssr: true and target: 'server' enables the usage of a serverMiddleware. Nuxt is also an Express server, so you could technically still totally hide stuff, the configuration of this one is detailed here. Please pay attention to the whole answer (especially the gotcha at the end).
The TDLR is as mentioned above: you'll need some kind of proxy to hide that, so you could do that:
directly with Nuxt2 but it's kinda tricky and hard to work with overall, on top of paying a whole Node.js server and a possible mistake exposing those tokens at some point
get another Node.js server to properly separate the concern and use that one as a proxy, it can be pretty light (no need for a beefy configuration), not as expensive price-wise
a serverless function could be the best idea here because it's light, cheap and you don't need to manage anything (send your query there, it will proxy the request with the secret token) but it can be a bit annoying regarding cold starts
I've read an article which used Cors-Anywhere to make an example url request, and it made me think about how easily the Same Origin Policy can be bypassed.
While the browser prevents you from accessing the error directly, and cancels the request altogether when it doesn't pass a preflight request, a simple node server does not need to abide to such rules, and can be used as a proxy.
All there needs to be done is to append 'https://cors-anywhere.herokuapp.com/' to the start of the requested url in the malicious script and Voila, you don't need to pass CORS.
And as sideshowbarker pointed out, it takes a couple of minutes to deploy your own Cors-Anywhere server.
Doesn't it make SOP as a security measure pretty much pointless?
The purpose of the SOP is to segregate data stored in browsers by their origin. If you got a cookie from domain1.tld (or it stored data for you in a browser store), Javascript on domain2.tld will not be able to gain access. This cannot be circumvented by any server-side component, because that component will still not have access in any way. If there was no SOP, a malicious site could just read any data stored by other websites in your browsers.
Now this is also related to CORS, as you somewhat correctly pointed out. Normally, your browser will not receive the response from a javascript request made to a different origin than the page origin it's running on. The purpose of this is that if it worked, you could gain information from sites where the user is logged in. If you send it through Cors-Anywhere though, you will not be able to send the user's session cookie for the other site, because you still don't have access, the request goes to your own server as the proxy.
Where Cors-Anywhere matters is unauthenticated APIs. Some APIs might check the origin header and only respond to their own client domain. In that case, sure, Cors-Anywhere can add or change CORS headers so that you can query it from your own hosted client. But the purpose of SOP is not to prevent this, and even in this case, it would be a lot easier for the API owner to blacklist or throttle your requests, because they are all proxied by your server.
So in short, SOP and CORS are not access control mechanisms in the sense I think you meant. Their purpose is to prevent and/or securely allow cross-origin requests to certain resources, but they are not meant to for example prevent server-side components from making any request, or for example to try and authenticate your client javascript itself (which is not technically possible).
I'm building a next.js project and while I usually would just use the "Custom Express Server" method to implement my graphql API (using apollo-server-express), I thought that it might be a good idea if I decoupled the next.js project from the graphql API so that each of the servers are hosted on different machines.
But usually I would implement any session-related logic in the graphql API, using something like graphql-passport; I figured that's good practice because if I ever choose to add another frontend (maybe a mobile app or something) they can share the same session logic. But given that I'm server side rendering content with next.js, how do I forward the user's session info to the graphql server? Because the next.js server shouldn't have to redo authentication, right?
Let me know if there are any flaws in the architecture too, I'm kind of new to this.
Using the Next server to run the GraphQL service is certainly not a good idea, so yes, do separate the two.
Letting the Next server SSR-render pages with user specific content using the users session is probably not a good idea either, unless you have some specific use case that requires the served HTML pages to have the user specific data in them already. The reasons for this are:
SSR rendering will require lots of server side computations since all pages always will have to be rerendered.
NextJS is moving away (since v9.3) from the getInitialPros() way of doing things towards using getStaticProps() to generate a page that is common for all users and which can load its session dependent stuff straight from the GraphQL API once it is displayed on the client device.
This approach will generally have higher performance and scale much better.
Should you really want to go the "SSR with user session data" route you start in the getServerSideProps(context) method, where context.req is the actual request which will have all your session data in it (cookies or headers).
This session data you can then extract from the req and pass on to the GraphQL server requests that require authentication.
I'm using Express to build a web site. I'm serving static files and have a REST API. For the static files I'm using the session middleware to restrict certain pages to logged in users. The downside to this is that the REST API has cookies in the HTTP header. Can I restrict certain routes to not use cookies? Is this what the mount function is for?
Well, if you're setting or requiring cookies, you must be using some sort of middleware function to do so (since there's nothing in Express per se that would do it). If you wrote the middleware function yourself, you just need to rewrite it to be a little more picky about when to set/require cookies. If you're using a pre-written middleware function, try putting it later in the stack than any route functions that shouldn't be requiring cookies (this will generally mean putting app.use(express.router); ahead of any app.use(...) call that invokes a cookie-dependent middleware function).
If this doesn't make sense to you, please post what you're doing (after stripping it down to a minimal test case).