Ok, let’s take a new BMW car.
You can say the car works perfectly fine for you and you are done. Of course you can’t understand everything in your car’s “framework” and it should not be something you have to be concerned about. Same applies to Xojo Web’s security pattern.
Even if your are a motor mechanic or a car tuner, you have to trust your APS system, you have to trust your airbags etc. You might be able to exchange such systems but you have to trust that the manufacturer of those devices have done their homework. The devices are sealed, you can’t do anything else then building them in and that’s fine (actually it is part of the security).
According to the BMW’s recommendation (until today) you can as well trust their keyless-go feature. But a considerable amount of cars in Germany are meanwhile stolen via devices you can buy online for a few EURs which capture the signal of your key. Once captured, the tool is manipulating this caught signal to open your car, deactivate your immobilizer and the thieve is ready to go in less than a minute. If he is fast enough to cross the border of the European Union, chances are very high that you will never see your car back again. You still have your key to reminisce …
Now I would not conclude that BMW engineers are stupid people. Every system can be hacked, or has perhaps backdoors which can be mis-used. But you can trust the system or you can take precautions when you were made aware of some risks. In the case of keyless-go systems it is apparently relatively easy to protect yourself: don’t leave your key on a window bench close to your car, put it into a drawer somewhere inside the house, leave it in your pocket or, if you are paranoid, put it into a metal box or wrap it into aluminium foil.
In coding for Web your Achilles heel is the login logic. If you do it wrong, people can inject SQL and even without authentication they can cause severe harm for your data. That’s not Xojo’s fault, it is our accountability to avoid it. Same applies to authorizations, so we should know all possible traps and trip hazards.
I am lucky that i don’t own a car, but I have a (legal) accountability towards my customer to protect their data. Now Xojo will not explain us in detail how their APS system is working but they shared already many best practises on this forum how to secure your compiled product.
All I want to ensure is if my understanding is right and if anyone has found some “broken” keyless-Go features, means if a Webpage could in theory be accessed via JavaScript injections or whatsoever, bypassing all my good intentions to protect the data in my code. This won’t happen out-of-the-box of course (that would imply a security patch from Xojo and is a different story), but I want to better understand what we developers have to ensure for not living on the edge and compromising the built-in security and to clarify what Xojo recommends to ensure max. security.
For instance we have seen many JavaScripts hacks on the forum (though not recommended by Xojo) to achieve whatsoever goals. Could such a JavaScript “injection” weaken the built-in security? I just don’t know, that’s why I’m asking.
And with Xojo Web we all depend mainly (at my current understanding) on the built-in functionality, which seems to be excellent, but only if we are using it in the right way.
In other non-xojo concepts, I can mistrust the vendor or mistrust my own coding capabilities and add some additional security layers, not so much with Xojo, so we need clarity how to use the tool in exactly the right way Xojo has designed it.
I am implementing my authorizations the same way you do. But this concept is proned for security leaks if not implemented everywhere. As you can’t yet check in the opening event if a webpage can be opened (or what should be shown on this page), you have to do it (like you do) BEFORE you are even calling a page. The risk is however, if you are later adding a webmenu item or a button on that page to open some other pages, then you have to ensure again to check against our defined roles before showing this page. This is where an approach to protect your page within itself regardless from where it is called has many benefits.
That’s the reason why I opened this thread, as I unfortunately jeopardized this thread. If the opening event would work like I expect it to work, I would be fine. Then we could implement our authorization checks into a sensitive page and won’t need to take care if in 5 months time we might by mistake forget to check our authorizations before(!) calling that page somewhere in our code. Your app won’t work the way you designed it and you have a bug, but at least you would not breach your security concept.