Implications of this? (Add generator message with info on how to secure a function)

I don’t know how I hit upon this PR, but reading it’s descriptions and associated threads left me feeling uncertain.

Could someone explain to me that my Redwood backend (is || is not) accessible outside of the frontend ?

And if it is (tho’ I have trouble believing this might be the case) - can we get instructions on how to close that gap ?

Thanks, I know everyone is fighting for every minute these days…

Al;

DT is the security keeper for Redwood and will have a much longer, more in depth answer than I can give. But for anyone seeing this and feeling worried, it’s worth mentioning that this is something fundamental to having a public endpoint on the internet that anyone can access.

That doesn’t excuse Redwood from having to think about these issues, and we likely have not done a good enough job communicating these inherent challenges. But this problem is not unique to Redwood in any respect.

This has received a lot of attention from the core team over the last few months which is why it’s surfacing in a PR, but keep your eyes on this forum post for a response from DT in the near future about what additional steps can be taken for mitigation.

Hi, Allen.

The short answer is “yes it is accessible outside … but that’s a good thing”. In fact, you rely on that to make your app used by people all around the world.

Let’s look at:

As you know, Redwood currently has two sides: web and api.

Your web is typically deployed to a CDN (via Netlify Netlify Edge | Netlify, Vercel, Render, etc) which makes your React (JS) app available on global edge nodes for speedy download to your users’ devices/clients. That’s the bottom row in the above diagram.

The top row is where your api is deployed, which is often AWS or other infra via Netlify, Vercel, Render, or even your own serverful deploy on hardware you manage.

I might be in Boston, Buenos Aires, Budapest, Brazzaville, Baku, Beijing, or Billings and my device is going to pull down the parts of the React app is needs from the closes part of the CDN it can reach anywhere it might be.

Once that client starts talking to the api, though, it is talking to where the API is deployed and say I deployed to Netlify, it’s probably sitting on some AWS machines in northern Virginia USA waiting for requests to come in.

Now, the api is simply a set of serverless functions – or API endpoints out there in the cloud. It’s going to talk to anything that asks it a question, that is formed in a way it can understand – and that you allow it to. More often than not, your data and features are completely public. But, in many cases it isn’t.

This is where securing your API is important. It’s going to be accessible – meaning pretty much any client can reach it, ie make an HTTP request … but that doesn’t mean it has to answer back or answer back nicely. If you don’t let it, it can return a 401 unauthorized (ok as we know GraphQL always responds with a 200 for some bizarro reason but it will also provide an error message).

It’s important to know that the RW GraphQL API is just a serverless function. This is why it is important to use authentication and require auth on the services and resolvers that are sensitive or should only be run by trusted actors. When you use Redwood auth, every GraphQL requests sends up in Authorization headers a Bearer access token that the API side will decode and can use to judge if some action or data is allowed by the user identified by that token.

These trusted actors can be authentication users (w/ or w/out roles and permissions). Or, these actors can be other systems like via Webhooks or even other apps using your API to enhance their experience.

So, TLDR; yes the api is accessible, but that’s to your app’s benefit however you need to be aware of what functions are open and limit their actions to trusted authorized actors.

Redwood will help you do this in a few ways:

Hope this helps and again – making it accessible is a good, even great, even amazing thing – you just need, as with anything you build, to make sure you keep sensitive data or actions behind something that checks if they are trusted.

If you have any questions or concerns, please let me or the Redwood Team know and happy to get on a chat to explain in more detail.

Securing Services by default […] This will be in an upcoming release.

What would be the most simple way to secure your app until it is the default ?

I opened a PR into the docs with this Excellent reply!

Al;

Thanks @ajoslin103 – in fact a security section in the RedwoodJS docs has been overdue and there is a current PR up for review

That addresses serverless functions and the new webhooks feature as a way to keep those up and running with confidence.

A section of GraphQL is upcoming that will include best practices and document some feature Redwood has in place to keep that GraphQL endpoint running smoothly.

Looking for comments and feedback on

and we can include any points you feel might be missing in this PR from yours.

Thanks for making sure RW documents security considerations.

Ha - I just saw your PR after I made my PR

I have added links to your new docs in my PR

I think we need to call out Security with it’s own Doc page

I am sorry that I don’t have time to grok what you’ve written – I’m on a deadline crunch on another product (react, typescript, electron) – I can’t wait for the Electron + Redwood combination !!

But my focus on my next whack at my Redwood app is to get secured w/social auth - so I’ll be reading your stuff then for sure

Redwood Rocks !!

1 Like

Good point. A dedicated section that does an intro and the link to the other noteworthy sections.

I’ll make a note of that in my PR and address.

Thanks!