Security:Data-loss: Difference between revisions
(New page: This page forms part of the Moodle security guidelines. ==What is the danger?== This is more a symptom or other vulnerabilities, than a vulnerability in its own ...) |
Dev Docs Bot (talk | contribs) m (Protected "Security:Data-loss": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{Template:Migrated|newDocId=/general/development/policies/security/dataloss}} | |||
This page forms part of the [[Security|Moodle security guidelines]]. | This page forms part of the [[Security|Moodle security guidelines]]. | ||
Line 39: | Line 40: | ||
* [[Coding]] | * [[Coding]] | ||
[[Category:Security]] | [[Category:Security]] |
Latest revision as of 07:27, 6 May 2022
Important:
This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date. Why not view this page on the new site and help us to migrate more content to the new site! |
This page forms part of the Moodle security guidelines.
What is the danger?
This is more a symptom or other vulnerabilities, than a vulnerability in its own right.
For example, Evil Hacker can use cross-site request forgery or SQL injection to maliciously destroy lots of your data. Or the fact that someone has permission to destroy a lot of data may indicate that the code is not performing sufficient authorisation checks.
However, it is also possible for users to accidentally destroy lots of data if the user-interface is badly designed and confusing.
How Moodle avoids this problem
We write secure code so that data cannot be destroyed maliciously.
We try to design clear interfaces, so that users understand the effects of their actions.
What you need to do in your code
- Actions that destroy a significant amount of data should have a confirmation step.
- Capabilities that let people destroy a lot of information should have RISK_DATALOSS.
- Follow the guidelines for avoiding
- Unauthorised access
- Cross-site request forgery (XSRF)
- SQL injection
- Command-line injection
- and so on.
What you need to do as an administrator
- Be careful!