[dddomodossola]

you are right, it requires further explanation. it is intended to be used on localhost and also on the web, preferably on safe networks like VPN. it implements ssl encription and a basic http authentication. technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. I consider it unsafe because I never spent enough time to test the framework penetration resistance.

[swinglock]

That's scary. Listening on localhost or serving a LAN/VPN behind a firewall does not make your web app secure from attackers on the Internet unless you air gapped. HTTP Basic Auth and HTTPS doesn't change that. Please do read up on CSRF.

This has been an issue for decades and just recently been in the news due to massive attacks against home routers (web apps listening on the LAN) and desktop apps (both web apps and web APIs listening on localhost). I get the impression that this has not been considered.

https://en.wikipedia.org/wiki/Cross-site_request_forgery

[dddomodossola]

thank you so much for the advice. however, as previously mentioned: technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. this means that the attacker have to know the ID of an object instance, in the actual running instance to point to a defined function.

however, the safety of an application is up to the developer, that can leave opened also the door of a safe atomic bunker

[swinglock]

Am I correct to interpret this as it's up to the app developer not to put any features that do anything of any importance in the web interface, because one should operate under the assumption that it's not only the logged on user in front of the computer (even when address='127.0.0.1') that can press the buttons?

Unless I'm completely misunderstanding I don't agree that is at all comparable with the security model expected of a "standard desktop gui framework" nor safe.

Though indeed if there are large, random and unpredictable IDs required to perform actions it may defeat or make the attack difficult.

[dddomodossola]

you are correct it could be theoretically pressed by someone else, but it should be really difficult because of the unpredictability of IDs. It should be simpler to attack flask or django based webinterfaces. doesn't it?

[swinglock]

Unpredictability is an inconvenience. Django and Flask does feature reliable protection.

https://docs.djangoproject.com/en/stable/ref/csrf/

https://flask-wtf.readthedocs.io/en/stable/csrf.html

[dddomodossola]

thank you for the advice. it should be pretty simple to protect an app from that kind of attacks. however this doesn't mean that remi is a safe web framework. personally I feel like @nicolaslem (look at his comment).

[swinglock]

nicolaslem recommended hosting behind a reverse proxy. That has nothing to do with the issue.

My recommendation is you read up on the subject and I'll leave it at that. You have been given everything needed to search for more information.