You don’t separate front and back for security reasons so much as performance ones. A server that handles static files is doing a very different job from one that handles dynamic responses, so there are optimisations for both that are typically suited to different servers.
A typical self-hosted environment for example might have one server running Nginx for the static files, and another one running your application server (gunicorn, uwsgi, whatever) for handling your REST server. While you can have your application server serve your static files, it’s not a great idea, since you end up busying the server with users downloading large static files on a slow connection.
Keeping them together or apart really has no bearing on security because you should never trust the client anyway. From the application server perspective, you always have to assume that the requestor can’t be trusted and act accordingly.
There are projects like WhiteNoise that allow you to host the two projects together, but I don’t recommend it for the above reasons.
As for the kinds of services that host this stuff, your static files can live anywhere, even with a cloud-based CDN if you want. For a simple self-hosted situation, you typically see something like this:
request --> nginx -- /media --> /some/local/folder/media
-- /static --> /some/local/folder/static
-- other --> forward to your app server (gunicorn/uwysgi/etc.)
That’s one Nginx instance sitting between your application and the client that checks if the request includes a path to a known-to-be-static file. If yes, then it just serves the file, and if no, then it relays the request to your application server. This is crude, but for small to medium-size projects, it’s often enough.
If you’re working with a cloud provider, you can get more creative and start hosting your static files in an entirely different place like an S3 bucket. Then, with a combination of other cloud configurations I can’t remember, you can say “handle static requests with S3 and app requests should be handled by this Kubernetes pod / lambda / some rando service running on an EC2 instance / whatever”.
When considering security, I wouldn’t spend too much time worrying about the front end. As I said earlier, you have to assume that it’s been compromised anyway, so building your app with that in mind protects you in that way. Make sure that no decisions are made client side that aren’t independently validated by the server side, and you should be ok.
There are a host of security concerns for the back-end though, many of which I don’t think I have space for here. Stuff like restricting cookies to HTTPS, and other things you see in Django’s SecurityMiddleware are a good place to start (Django’s official docs are really helpful here). Over and above that, rate limiting is good for reducing brute force attacks, locking accounts with suspicious activity, etc. etc. All important stuff, and all entirely back-end related.