I did something similar* with CKEditor and the id+key after the "#" like 3-4 years back when I was learning about real time and cryptography.
There were few practical problems that could not be easily resolved, the main one being that the server could send a different javascript payload (by modifying the HTML src) that leaks everything for specific clients and they wouldn't even know.
The most reasonable solution would be a plugin of sorts that freezes the front-end code and checks that the html+javascript has not been modified since last time, but this wouldn't be practical and has a totally different set of problems.
This scenario could happen if we consider real-world scenarios (imperfect/bad actors):
- Rogue hosting or admin: someone who controls the server decides to change the javascript. They are smart enough to change the checksum in the <script> so things still validate.
- Cracked ("Hacked"): there is a vulnerability in some part of the stack and the javascript gets changed unknowingly by the server admins.
- MITM for a badly configured server that accepts "http:" instead of "https:" and the user connects through a public network. Actually, the fact that it redirects http to https has its own set of problems for the people who might need this: http://security.stackexchange.com/q/44849/9161
Did you solve this? If so, how?
*I did the proof of concept mixing front with back-end and never fully ported it to front-end for the problems explained above.
- Send HSTS header in your code, instead of relying on the server).
- Drop the connection if it is not secure. This breaks a reverse-proxy setup though.
There were few practical problems that could not be easily resolved, the main one being that the server could send a different javascript payload (by modifying the HTML src) that leaks everything for specific clients and they wouldn't even know.
The most reasonable solution would be a plugin of sorts that freezes the front-end code and checks that the html+javascript has not been modified since last time, but this wouldn't be practical and has a totally different set of problems.
This scenario could happen if we consider real-world scenarios (imperfect/bad actors):
- Rogue hosting or admin: someone who controls the server decides to change the javascript. They are smart enough to change the checksum in the <script> so things still validate.
- Cracked ("Hacked"): there is a vulnerability in some part of the stack and the javascript gets changed unknowingly by the server admins.
- MITM for a badly configured server that accepts "http:" instead of "https:" and the user connects through a public network. Actually, the fact that it redirects http to https has its own set of problems for the people who might need this: http://security.stackexchange.com/q/44849/9161
Did you solve this? If so, how?
*I did the proof of concept mixing front with back-end and never fully ported it to front-end for the problems explained above.