DokuWiki Security Hardening — .htaccess, File Permissions, SSL, and Security Headers

In this tutorial, you'll learn how to harden DokuWiki security, including .htaccess protection for sensitive directories, file permission hardening, SSL/TLS configuration, security headers, PHP security settings, and regular security audit procedures.

What You'll Learn

• Securing sensitive directories with .htaccess
• Hardening file permissions
• SSL/TLS configuration
• Security headers (CSP, HSTS, X-Frame-Options)
• PHP security settings
• DokuWiki-specific security configuration
• Security audit and monitoring

Why It Matters

DokuWiki's flat-file architecture reduces some attack vectors (no SQL Injection), but it has its own security considerations. Sensitive files (configuration, user data, revision history) must be protected from direct web access. Without proper hardening, an attacker who gains file read access can steal user accounts, configuration secrets, and page content.

Real-World Use

A security audit reveals that a DokuWiki installation is vulnerable: conf/ directory is accessible via web browser (exposing users.auth.php with password hashes). The admin adds .htaccess protection to conf/, data/, and inc/ directories, enables HTTPS with HSTS, sets restrictive file permissions, adds security headers, and enables automatic security update notifications. The re-audit passes with no critical findings.

Learning Path

flowchart LR
  A[Performance] --> B[Security]
  B --> C[Production]
  C --> D[Conclusion]

Securing Sensitive Directories with .htaccess

DokuWiki ships with .htaccess files in sensitive directories, but verify they are present and correct.

conf/ Directory

# conf/.htaccess
Deny from all

This prevents anyone from accessing acl.auth.php, users.auth.php, or local.php directly via the web.

data/ Directory

# data/.htaccess
Deny from all

Without this, attackers could download all page files, media files, and revision history.

inc/ Directory

# inc/.htaccess
Deny from all

lib/ Directory

For lib/, allow access to specific subdirectories while blocking others:

# lib/.htaccess
Deny from all

# But allow access to plugin and template resources
<FilesMatch "\.(css|js|png|jpg|gif|svg)$">
    Allow from all
</FilesMatch>

File Permission Hardening

Recommended Permissions

# Core directories (read-only for web server)
chmod 755 /var/www/html/wiki/inc/
chmod 755 /var/www/html/wiki/vendor/

# Configuration (read only, write when changing config)
chmod 644 /var/www/html/wiki/conf/*.php
chmod 644 /var/www/html/wiki/conf/*.txt

# User content (needs write access)
chmod 777 /var/www/html/wiki/data/
chmod 777 /var/www/html/wiki/data/pages/
chmod 777 /var/www/html/wiki/data/media/
chmod 777 /var/www/html/wiki/data/attic/
chmod 777 /var/www/html/wiki/data/cache/
chmod 777 /var/www/html/wiki/data/index/
chmod 777 /var/www/html/wiki/data/meta/

# Plugins and templates (write only during install/update)
chmod 755 /var/www/html/wiki/lib/plugins/
chmod 755 /var/www/html/wiki/lib/tpl/

Ownership

# Set owner to web server user
chown -R www-data:www-data /var/www/html/wiki/

# On shared hosting, use your FTP user as owner
chown -R user:group /var/www/html/wiki/

Remove World-Readable Permissions

# Ensure sensitive files are not world-readable
chmod 640 /var/www/html/wiki/conf/local.php
chmod 640 /var/www/html/wiki/conf/acl.auth.php
chmod 640 /var/www/html/wiki/conf/users.auth.php

SSL/TLS Configuration

Redirect HTTP to HTTPS

# Apache: Force HTTPS
<VirtualHost *:80>
    ServerName wiki.example.com
    Redirect permanent / https://wiki.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName wiki.example.com
    DocumentRoot /var/www/html/wiki
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/wiki.crt
    SSLCertificateKeyFile /etc/ssl/private/wiki.key
</VirtualHost>

# Nginx: Force HTTPS
server {
    listen 80;
    server_name wiki.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name wiki.example.com;
    ssl_certificate /etc/ssl/certs/wiki.crt;
    ssl_certificate_key /etc/ssl/private/wiki.key;
}

HSTS (HTTP Strict Transport Security)

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Security Headers

Add these headers to your web server configuration:

# Apache security headers
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

# Nginx security headers
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'" always;

PHP Security Settings

php.ini Recommendations

; Disable dangerous functions
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

; Resource limits
memory_limit = 256M
max_execution_time = 120
max_input_time = 60

; File uploads
file_uploads = On
upload_max_filesize = 64M
post_max_size = 64M

; Error reporting (disable in production)
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log

; Session security
session.use_strict_mode = 1
session.use_cookies = 1
session.use_only_cookies = 1
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Strict"

DokuWiki Security Configuration

Disable Unnecessary Actions

<?php
// conf/local.php
$conf['disableactions'] = 'register,export_pdf';  // Disable registration and PDF export

Set Strong Admin Password

Use a password manager to generate and store a strong admin password.

Enable Login Throttling

<?php
// conf/local.php
$conf['usefloodprotection'] = 1;    // Enable flood protection
$conf['protectmail'] = 1;           // Obfuscate email addresses

Automatic Security Checks

DokuWiki checks for security issues on the admin page. Review the "Security" section regularly.

Regular Security Audits

Automated Security Check Script

#!/bin/bash
# security-audit.sh

WIKI_DIR="/var/www/html/wiki"

echo "=== DokuWiki Security Audit ==="
echo "Date: $(date)"
echo ""

# Check 1: install.php exists?
if [ -f "$WIKI_DIR/install.php" ]; then
    echo "WARNING: install.php still exists! DELETE IT NOW."
else
    echo "OK: install.php is removed."
fi

# Check 2: .htaccess files exist
for dir in "conf" "data" "inc"; do
    if [ -f "$WIKI_DIR/$dir/.htaccess" ]; then
        echo "OK: $dir/.htaccess exists."
    else
        echo "WARNING: $dir/.htaccess is missing!"
    fi
done

# Check 3: File permissions
if [ -r "$WIKI_DIR/conf/local.php" ]; then
    PERM=$(stat -c "%a" "$WIKI_DIR/conf/local.php")
    echo "INFO: conf/local.php permissions: $PERM (recommended: 640)"
fi

# Check 4: SSL enabled?
if curl -s -o /dev/null -w "%{http_code}" https://localhost/wiki/ 2>/dev/null; then
    echo "OK: HTTPS is accessible."
else
    echo "WARNING: HTTPS check failed."
fi

# Check 5: DokuWiki version
echo "INFO: Checking for updates..."
VERSION=$(grep "DOKU_VERSION" "$WIKI_DIR/inc/init.php" | head -1)
echo "  $VERSION"

echo ""
echo "Audit complete."

Common Security Threats

Common Mistakes

1. Leaving install.php accessible: This is the most common and dangerous mistake. Delete install.php immediately after installation.
2. Setting 777 permissions on everything: Permissive permissions are convenient but insecure. Use the minimum permissions required.
3. Not enabling HTTPS: Without SSL, login credentials and page content are transmitted in plaintext. Always use HTTPS.
4. Ignoring .htaccess files: If .htaccess files are missing or not honored (Apache AllowOverride disabled), sensitive directories are exposed.
5. Using weak passwords: Admin accounts with weak passwords are vulnerable to brute force. Use a password manager.

Practice Questions

1. What directories must be protected with Deny from all in .htaccess, and why?
2. What security headers should you configure for a DokuWiki site, and what does each do?
3. How do you verify that install.php has been deleted and that .htaccess files are properly protecting sensitive directories?
4. Challenge: Perform a comprehensive security audit on a DokuWiki installation. Check: install.php is deleted, .htaccess files exist in conf/, data/, and inc/, HTTPS is properly configured with HSTS, security headers are present (CSP, X-Frame-Options, X-Content-Type-Options), file permissions are set correctly (640 for conf files, 755 for directories), PHP dangerous functions are disabled, DokuWiki version is up to date, admin password is strong, and no unnecessary actions are enabled. Document each finding, categorize by severity (critical, high, medium, low), and implement fixes for all critical and high findings.

FAQ

Mini Project

Goal: Harden a DokuWiki installation against common threats.

1. Run the security audit script and document findings
2. Delete install.php if it exists
3. Verify .htaccess files are present in conf/, data/, and inc/
4. Enable HTTPS (use Let's Encrypt for free SSL)
5. Configure HSTS and security headers
6. Set correct file permissions (640 for config files, 755 for directories)
7. Disable dangerous PHP functions
8. Enable DokuWiki flood protection
9. Change admin password to a strong, generated password
10. Re-run the security audit to verify all fixes
11. Create a security maintenance schedule (weekly checks, quarterly audits)

What's Next

Security hardening protects your wiki. Now learn about production deployment with Nginx, monitoring, and scaling.