Wordpress security has been, and always will be, a hot liquid steaming mess. Without security controls over plugins, including sandboxing, the entirety of it is vulnerable in ways amateurs cannot begin to manage.
WordPress itself is solid. WordPress's overly permissive plugin system is both its biggest strength and biggest weakness. It's like Firefox and XUL in that way: you can do anything with anything. Which is great! But you can also do anything with anything, which is bad.
In a greenfield, there are several techniques I would use to develop a CMS plugin system:
- Decoupling through a process boundary interacting via RPC (This expands plugin backends to be able to be written in other languages or even compiled. Front-end plugin components could/would need to be rendered and composited separately in a way that cannot leak out.)
- Require administrative approval to grant particular permissions
- Cryptographic signatures of plugins by authors and web-of-trust maintained by Wordpress
- Capability-based API that can only be invoked after delegated permissions as above
9 comments
[ 2.7 ms ] story [ 30.9 ms ] thread- Decoupling through a process boundary interacting via RPC (This expands plugin backends to be able to be written in other languages or even compiled. Front-end plugin components could/would need to be rendered and composited separately in a way that cannot leak out.)
- Require administrative approval to grant particular permissions
- Cryptographic signatures of plugins by authors and web-of-trust maintained by Wordpress
- Capability-based API that can only be invoked after delegated permissions as above
PS: Project to remove XUL https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf...