Skip to content

The aim of the checklist is to provide a comprehensive list of security best practices that developers can use to secure their Moodle plugins.

Notifications You must be signed in to change notification settings

emeneo/Moodle-plugin-security-checklist

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 

Repository files navigation

Moodle plugin security checklist

⬜ Not checked yet     ✅ checked
No. Description Reference Status
001 Use latest security checklist Latest Moodle plugin security checklist
002 Do not access superglobals like $_REQUEST, $_GET, $_POST and $_COOKIE directly. Use wrappers like required_param() and optional_param() with correct type declared to sanitize input. Make sure you pick the most specific PARAM type for each of the parameters. Plugin Contribution Checklist 3.10 Security, Moodle Traffic forum
003 Always use data placeholders in custom SQL queries (? or :named) to pass data from users into the queries Plugin Contribution Checklist 3.10 Security Forum Post
004 Check for require_login(). Plugin Contribution Checklist 3.10 Security
005 Always check that the user has appropriate capabilities before displaying widgets/ action links (has_capability() is typically used there) Plugin Contribution Checklist 3.10 Security , Moodle Traffic forum
006 Always check users capabilities just before you actually perform the action (call require_capability()) Plugin Contribution Checklist 3.10 Security , Moodle Traffic forum
007 Always check for the sesskey before taking an action on submitted data. Plugin Contribution Checklist 3.10 Security
008 Avoid using malicious functions like call_user_func(), eval(), unserialize() and so on, especially when they would be called with user-supplied data Plugin Contribution Checklist 3.10 Security
009 Use the Form API whenever possible for handling HTML forms Security guidelines
010 GET requests should be used for getting information. So, for example, viewing a user's profile should be a GET request.POST requests should be used for changing things in the application. For example deleting a user should be a POST request. Security guidelines
011 Never display the Sesskey in the browser url bar or similar Secuirty guidelines
012 Do not require outdated / insecure moodle plugins
013 Do not include third party library code in your plugin package which are already provided by moodle core (e.g jQuery) Moodle thrid party libraries
014 Keep included third party libraries up to date
015 Never put any passwords etc. into the code/ comments

About

The aim of the checklist is to provide a comprehensive list of security best practices that developers can use to secure their Moodle plugins.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published