others edit pages in your wiki, then some possible security issues do need
to be kept in mind.
+[[toc levels=2]]
+
----
# Probable holes
Login to the wiki involves sending a password in cleartext over the net.
Cracking the password only allows editing the wiki as that user though.
-If you care, you can use https, I suppose.
+If you care, you can use https, I suppose. If you do use https either for
+all of the wiki, or just the cgi access, then consider using the sslcookie
+option.
## XSS holes in CGI output
It's difficult to know for sure if all such avenues have really been
closed though.
+## HTML::Template security
+
+If the [[plugins/template]] plugin is enabled, users can modify templates
+like any other part of the wiki. This assumes that HTML::Template is secure
+when used with untrusted/malicious templates. (Note that includes are not
+allowed, so that's not a problem.)
+
+----
+
+# Plugins
+
+The security of [[plugins]] depends on how well they're written and what
+external tools they use. The plugins included in ikiwiki are all held to
+the same standards as the rest of ikiwiki, but with that said, here are
+some security notes for them.
+
+* The [[plugins/img]] plugin assumes that imagemagick/perlmagick are secure
+ from malformed image attacks. Imagemagick has had security holes in the
+ past. To be able to exploit such a hole, a user would need to be able to
+ upload images to the wiki.
+
----
# Fixed holes
point. #[378412](http://bugs.debian.org/378412) could affect us, although it
doesn't seem very exploitable. It has a simple fix, and has been fixed in
Debian unstable.
+
+## include loops
+
+Various directives that cause one page to be included into another could
+be exploited to DOS the wiki, by causing a loop. Ikiwiki has always guarded
+against this one way or another; the current solution should detect all
+types of loops involving preprocessor directives.