I built a full-stack app, how should I host it?
from echodrift@programming.dev to programming@programming.dev on 15 Dec 22:52
https://programming.dev/post/22888628

So basically I built a backend with some working endpoint and I built a React Frontend. I can run both things locally and I hosted the page on Cloudflare pages which is working. But now I’m wondering if that’s a good idea?

I have never done this before and I’m wondering if it’s secure enough to host the backend on some server and allow a CORS header to let the Frontend generate requests?

The alternative would be to host Frontend and backend on a VPS and then route my domain that I bought on Cloudflare there, but then I’m thinking that in case my Frontend is insecure somehow the whole instance would be compromised, no?

I hope this is the right platform to ask as I’m pretty new here.

#programming

threaded - newest

MajorHavoc@programming.dev on 15 Dec 23:59 next collapse

I have never done this before and I’m wondering if it’s secure enough to host the backend on some server and allow a CORS header to let the Frontend generate requests?

As long as you can get it working without putting any wildcards (asterix *) in your CORS headers, you’re using CORS as intended, and should be fine.

The alternative would be to host Frontend and backend on a VPS and then route my domain that I bought on Cloudflare there, but then I’m thinking that in case my Frontend is insecure somehow the whole instance would be compromised, no?

Back in my day we almost always hosted the front end and the back end on the same host. Of course, we also did a lot of stupid shit back then.

It’s not a disaster to host them the same place, but it’s certainly not a best practice. It’s better to get the CORS headers working, if you can. But just hosting them the same place isn’t, by itself, a security issue. It enables a shit ton of other security mistakes to be cause a lot more harm. But it’s not, itself, a problem.

Edit: Bonus tip. You probably know this, but lots of newbies miss it. Every piece of code and config in your front end app is optional to me and to all bad actors. So take care you don’t put any important secrets or critical defensive decision logic there.

echodrift@programming.dev on 17 Dec 02:06 collapse

Thanks, this is reassuring. Yeah I don’t really know what I’m doing with the headers but trying my best to be as restrictive as possible. I think I’m still doing something wrong with the headers because I can’t seem to connect to the backend when the fronting is deployed.

Yeah I’m super paranoid about what I’m exposing, I made sure that there are no environment variables or secrets exposed.

MajorHavoc@programming.dev on 17 Dec 03:09 collapse

Hang in there. CORS is a huge pain in the ass on the best day.

That said, if the issue is CORS, there should be a pretty specific message in the browser debug menu. Note that, if I’ve read that page correctly, the error won’t be available to JavaScript runtime, as an intentional security “feature”.

andioop@programming.dev on 16 Dec 01:22 next collapse

Hey, could you switch language to English? Lemmy says you made this post in a different language.

Max_P@lemmy.max-p.me on 16 Dec 04:49 collapse

Misconfigured CORS is no worse than someone using curl, or postman, or any other tool of that kind. What could compromise your server is the backend side of things, the frontend is just a limited HTTP client in the end. The real risk is those making direct requests to your server. CORS is just an ask for browsers specifically to stop cross domain communication, it protects the users not you.

You can help that a lot by using containers like Docker or Podman, but you should also make sure your backend is secure. But the most risk really even then would usually be, break into your database via SQL injection or something like that, still not breaking into the whole instance.

If anything, making sure to use SSH keys, disable root login and general server best practices is way more important than your app. You’re more likely that your server itself will be attacked than the backend. Security comes in layers.

But realistically you’ll be fine, and if you do end up hacked, it’s a learning experience.

MajorHavoc@programming.dev on 16 Dec 06:55 next collapse

CORS is just an ask for browsers specifically to stop cross domain communication, it protects the users not you.

A minor point of clarification to this point.

CORS also provides substantial protection to the server admin against innocent users being manipulated into taking malicious actions.

So there is some value to the server admin as well.

Sure, any malicious actor can assault the back end directly, but often they have no ability to attack from a context of authenticated trust.

A CORS misconfiguration makes the system more vulnerable to attacks that manipulate legitimate users into taking malicious actions.

So a CORS misconfiguration can lead to malicious actions coming in through highly trusted contexts, which can sometimes be substantially more harmful that random unauthenticated attack spam.

echodrift@programming.dev on 17 Dec 02:14 collapse

That’s an interesting perspective. I am pretty paranoid and I run the backend API in docker from a non-root user. I am pretty paranoid but kinda clueless doing all of this myself, I did use an ssh key that requires a yubikey to login to the VPS and I don’t store any secrets on the VPS it‘s all managed via GitLab.

I’m just getting started, so there’s not even a DB currently, not yet needed. I would want to run everything over k8s eventually, and was considering hosting gitlab myself for the experience and because I can’t afford paying for the CI/CD stuff.

Does it make sense to run everything on a separate instance from a security perspective? I’m already having nightmares from thinking about the networking between all of that :D

Max_P@lemmy.max-p.me on 17 Dec 03:28 collapse

There’s definitely security advantages to running things across multiple instances: if one gets hacked, the others are unaffected.

The networking should be pretty simple for what you’re doing. A few things just change to like 127.0.0.1 to something like 172.31.X.X or whatever IPs your VPC ends up using.

It looks like you’re doing very well, I’ve seen big companies with less security than that.