Development:Security

This page describes how security best practices for Moodle developers, and how to use the Moodle API to achieve the best security for your scripts.

General

1. Always try to structure your code in classes and functions without using globals ... this will promote better checking and tracing of variables.

Authentication

1. Each file should check that the user is authenticated correctly, using require_login() and has_capability() or require_capability().

Handling input

1. Do not rely on 'register_globals'. Every variable must be properly initialised in every code file. It must be obvious where the variable came from.
2. Do not ever use $_GET, $_POST or $_REQUEST. Use the appropriate required_param() or optional_param() appropriate to your need.
3. Do not use data from $_SERVER if you can avoid it. This has portability issues. Instead, use Moodle functions to get what you want.
4. Wherever possible group all your required_param(), optional_param() and other variables initialisation at the beginning of each file to make them easy to find.
5. Initialise all arrays and objects, even if empty. $a = array() or $obj = new stdClass();.
6. Use 'sesskey' mechanism to protect form handling routines from attack. Basic example of use: when form is generated, include <input type="hidden" name="sesskey" value="<?php echo sesskey(); ?>" />. When you process the form check with if (!confirm_sesskey()) { print_error('confirmsesskeybad');}.
7. If you presenting a normal form and processing it, always use the moodleforms library - it will take care of most details for you.

Storing data

1. Try to always use the XMLDB library in Moodle for all database access. Not only does this provide security but it ensures correct behaviour on different databases.
2. If you must write custom some SQL code, make very sure it is correct. In particular watch out for missing quotes around values to avoid possible SQL 'injection' exploits.
3. Before Moodle 2.0, any data sourced from the database MUST have addslashes() applied to it BEFORE it can be written back. A whole object of data can be processed at once with addslashes_object().
4. In Moodle 2.0 and later the database layer has changed and you MUST NOT use addslashes() anywhere as this is now automated.

Output

1. All texts should be printed using the format_text() function, especially those that have come from users. This ensures that text is filtered and cleaned correctly. More information can be found on the page about output functions.

Logging

1. User actions should be logged using the add_to_log() function. These logs are used for activity reports and Logs.

Shell commands

1. Avoid them! However, if you must use shell_exec() (or any other shell invoking function), make sure you clean parameters first with escapeshellcmd()/escapeshellarg (to prevent shell injection attacks).