Opened 4 weeks ago
Closed 11 days ago
#63304 closed feature request (wontfix)
Proposal: Permission-Based Access Control for Plugins in WordPress Core
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
Dear WordPress Core Team,
I hope you're doing well.
I’d like to propose a new feature for WordPress core that I believe would significantly enhance the platform’s overall security and transparency—especially in the context of third-party plugin management.
🧩 Feature Proposal: Plugin Permission System (Inspired by Mobile OS Models)
Problem:
Currently, WordPress plugins have unrestricted access to server files, the entire database, and system functions once activated. This "all-or-nothing" model lacks a layer of permission-based control, which poses major risks—especially for less-experienced site administrators who install plugins without a clear understanding of what those plugins do behind the scenes.
Proposed Solution:
Introduce a permission request system at the time of plugin installation/activation, similar to the model used in mobile operating systems like Android or iOS.
Plugins would be required to declare their intended capabilities such as:
Read/write access to specific directories (e.g. wp-content/uploads, theme folders, etc.)
Access to specific database tables (e.g. wp_users, custom tables)
Usage of certain PHP functions (e.g. file_get_contents, exec, etc.)
External API access or remote file operations
These permissions would be presented to the site administrator in a clear and user-friendly interface during installation, allowing for either:
Accepting the required permissions
Rejecting the plugin installation if permissions are deemed too invasive
Optional Advanced Implementation (Stretch Goal):
A plugin sandboxing framework that isolates plugin operations and enforces the granted permissions dynamically using hooks, wrappers around critical APIs (e.g. wpdb, Filesystem API, etc.), and static code analysis.
🚀 Benefits:
Enhanced security: Limit the blast radius of malicious or poorly written plugins.
User transparency: Admins understand exactly what a plugin is trying to access.
Developer responsibility: Encourages cleaner and more modular code practices.
Aligns with modern software practices: Inspired by OS-level app permissions.
🔧 Backward Compatibility:
To ensure a smooth transition, this could start as an optional opt-in feature or be enforced only on newly submitted plugins to the WordPress plugin repository, similar to how plugin guidelines and reviews have evolved.
🔚 Conclusion:
WordPress has always been about empowering users—but with power comes the need for safe boundaries. I genuinely believe this feature would be a huge leap forward in making the ecosystem more secure and trustworthy.
I’d be more than happy to contribute ideas, mockups, or help further if the core team is interested in exploring this proposal.
Thank you for considering this suggestion, and for your continued dedication to improving WordPress.
Best regards,
[matin boronsi]
Change History (3)
#2
in reply to:
↑ description
@
4 weeks ago
Replying to matinlk:
Dear WordPress Core Team,
I hope you're doing well.
I’d like to propose a new feature for WordPress core that I believe would significantly enhance the platform’s overall security and transparency—especially in the context of third-party plugin management.
I find it pretty great, problem is that it's seriously challenging to make this, if not impossible. The main difference is that plugins operate completely independently of the WordPress core. They are entirely separated apps, contrarily to an app say in Android or iOS, where they control the underlying system. Nothing can inhibit a plugin to using a pure PHP function (at most a wp-equivalent function, but still this could be easily bypassed)
So technically, this feature is not feasible without rebuilding some sort of underlying system for plugins. And still, I'm almost confident that this is not possible.
But there could be a trust-based permission system, where plugin creators declare their permission intentions and these are listed. This could only rely on a full trust-basis and, at most, some mod review (Although I'm sure 1000% that the Plugin Team will be completely against this).
Another idea that comes to my mind is something similar to WP Tide, a full plugin automated reviewer checking for certain PHP function uses. Again, very challenging, but this is more feasible.
Replying to ayeshrajans:
Wow this has to be the most obvious LLM-worded ticket description.
Yes, 50/50 I would say, but not worse than the whole fricking series of PR that plenty of contributors are sending lately (in particular, for unit testing, it hurts my liver, specially when have to review it).
#3
@
11 days ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
This is clearly not something doable in short/middle term in WordPress (see the detailed answer in the previous comment). Closing this ticket for now. Feel free to reopen it when a patch proposal is available for testing (but I seriously doubt it's doable).
Wow this has to be the most obvious LLM-worded ticket description.