Zend Framework 1 Security Hardening Checklist for Modern PHP Runtimes

Zend Framework 1 Security Hardening Checklist for Modern PHP Runtimes

The framework is old. Your security posture does not have to be.

Running Zend Framework 1 in 2026 is a maintenance reality for thousands of PHP teams. The framework stopped receiving official security patches years ago, which means the burden of security hardening falls entirely on you. The good news is that most of the attack surface in a ZF1 application is not in the framework itself but in how you use it. You can close the majority of security gaps without touching the framework internals.

This checklist covers the practical hardening steps for a ZF1 application running on PHP 8.x. Each item is actionable and can be applied incrementally. You do not need to complete everything at once, but you should have a plan to work through every section within a quarter.

For the PHP runtime upgrade that should accompany this hardening work, see the Zend Framework 1 on PHP 8.5 playbook.

Input Validation and Filtering

Use Zend_Filter_Input Consistently

ZF1’s Zend_Filter_Input component provides a structured approach to input validation and filtering. Many ZF1 applications bypass it and access $_GET, $_POST, or $_REQUEST directly. This is the single most common security gap in ZF1 codebases.

What to check:

  • Search your codebase for direct superglobal access: grep -rn '\$_GET\|\$_POST\|\$_REQUEST\|\$_COOKIE' application/
  • Every instance should be replaced with either Zend_Filter_Input or the controller’s getRequest()->getParam() with explicit validation afterward
  • Form submissions should use Zend_Form with validators attached to each element

Why it matters on modern PHP:
PHP 8.x is stricter about type handling. A $_GET parameter that was silently cast to an integer in PHP 7.x may now produce a TypeError or unexpected behaviour. Using Zend_Filter_Input with explicit type filters catches these at the entry point.

Validate All Route Parameters

The controller’s $this->getRequest()->getParam('id') returns a string. If your model layer expects an integer, validate before passing:

1
2
3
4
$id = (int) $this->getRequest()->getParam('id');
if ($id <= 0) {
    throw new Zend_Controller_Action_Exception('Invalid ID', 404);
}

Do not trust the router to enforce parameter types. ZF1’s segment routes accept any string in any position.

SQL Injection Prevention

Audit Every Database Query

ZF1 applications commonly use three query patterns:

  1. Zend_Db_Table methods (find(), fetchAll(), fetchRow()) with array conditions - these are safe when you use parameter binding
  2. Zend_Db_Select query builder - safe when you use where('column = ?', $value) with the placeholder
  3. Direct SQL via $db->query() - safe only if you use prepared statements

The dangerous pattern is string interpolation:

1
2
3
4
5
// VULNERABLE - never do this
$rows = $db->fetchAll("SELECT * FROM users WHERE email = '$email'");

// SAFE - parameter binding
$rows = $db->fetchAll("SELECT * FROM users WHERE email = ?", [$email]);

Search for interpolated queries:

1
grep -rn 'fetchAll\|fetchRow\|query\|fetchOne' application/ | grep '\$'

Review every match. Any query that includes a PHP variable inside the SQL string without a ? placeholder is a potential injection point.

Use Zend_Db_Select for Complex Queries

The query builder automatically handles quoting and parameter binding:

1
2
3
4
5
6
$select = $db->select()
    ->from('users')
    ->where('email = ?', $email)
    ->where('status = ?', 'active')
    ->order('created_at DESC')
    ->limit(10);

This is not just safer. It is also more portable and easier to audit than concatenated SQL strings.

Session Security

Configure Zend_Session Properly

The default session configuration in most ZF1 applications is insecure by modern standards. Update your application.ini or bootstrap:

1
2
3
4
5
6
7
8
9
10
11
; Session configuration
resources.session.save_path = APPLICATION_PATH "/../data/sessions"
resources.session.gc_maxlifetime = 1800
resources.session.cookie_lifetime = 0
resources.session.cookie_httponly = true
resources.session.cookie_secure = true
resources.session.cookie_samesite = "Lax"
resources.session.use_strict_mode = true
resources.session.use_only_cookies = true
resources.session.sid_length = 48
resources.session.sid_bits_per_character = 6

Critical settings:

  • cookie_httponly = true prevents JavaScript from accessing the session cookie (mitigates XSS session theft)
  • cookie_secure = true ensures the cookie is only sent over HTTPS
  • cookie_samesite = "Lax" mitigates CSRF via cross-site requests
  • use_strict_mode = true rejects unrecognised session IDs (prevents session fixation)

Regenerate Session ID After Authentication

After a successful login, always regenerate the session ID:

1
Zend_Session::regenerateId();

This prevents session fixation attacks where an attacker sets a known session ID before the user authenticates.

Set Session Validators

ZF1 provides session validators that detect suspicious session reuse:

1
2
3
4
Zend_Session::setOptions([
    'remember_me_seconds' => 1800,
]);
Zend_Session::registerValidator(new Zend_Session_Validator_HttpUserAgent());

The HttpUserAgent validator detects if the user agent changes mid-session, which can indicate session hijacking. It is not foolproof but adds a layer of detection.

Cross-Site Request Forgery (CSRF) Protection

Add CSRF Tokens to Every State-Changing Form

ZF1’s Zend_Form_Element_Hash provides CSRF protection:

1
2
3
4
$form->addElement('hash', 'csrf_token', [
    'salt' => 'unique_form_salt_' . get_class($form),
    'timeout' => 1800,
]);

Every form that changes server state must include a CSRF token. This includes:

  • Login forms
  • Profile update forms
  • Settings changes
  • Delete confirmations
  • Any AJAX endpoint that modifies data

Verify CSRF Tokens on POST Processing

The CSRF token check happens during form validation:

1
2
3
4
5
6
7
if ($this->getRequest()->isPost()) {
    if ($form->isValid($this->getRequest()->getPost())) {
        // Token is valid, process the form
    } else {
        // Token is invalid or expired
    }
}

Do not skip isValid() on forms that have the hash element. The hash check is part of the validation chain.

Cross-Site Scripting (XSS) Prevention

Escape All Output

ZF1’s view layer does not automatically escape output. Every variable rendered in a view script must be explicitly escaped:

1
2
3
4
5
<!-- VULNERABLE -->
<p><?php echo $this->username; ?></p>

<!-- SAFE -->
<p><?php echo $this->escape($this->username); ?></p>

The escape() method in Zend_View uses htmlspecialchars() with appropriate flags. For attribute contexts, ensure you are also quoting attributes:

1
2
<!-- SAFE in attribute context -->
<input value="<?php echo $this->escape($this->value); ?>">

Audit View Scripts for Unescaped Output

1
grep -rn 'echo \$this->' application/views/scripts/ | grep -v 'escape\|partial\|render\|headScript\|headLink\|headMeta'

Every match that does not use escape() is a potential XSS vector. Fix them all.

Content Security Policy Headers

Add a Content Security Policy header to restrict what the browser can execute:

1
2
3
4
5
// In your bootstrap or a front controller plugin
$this->getResponse()->setHeader(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'"
);

CSP is your last line of defence. Even if an XSS vulnerability exists, a strict CSP prevents the injected code from loading external resources or executing inline scripts.

Authentication and Password Handling

Use bcrypt or Argon2 for Password Hashing

ZF1 applications often use MD5 or SHA1 for password hashing. Replace these immediately:

1
2
3
4
5
6
7
8
9
10
// DANGEROUS - replace immediately
$hash = md5($password);

// CORRECT - use PHP's native password hashing
$hash = password_hash($password, PASSWORD_ARGON2ID);

// Verification
if (password_verify($password, $storedHash)) {
    // authenticated
}

PHP’s password_hash() and password_verify() functions handle salt generation, algorithm selection, and cost tuning. There is no reason to use anything else.

Implement Account Lockout

After a configurable number of failed login attempts, lock the account temporarily:

1
2
3
4
5
6
7
8
9
10
11
$maxAttempts = 5;
$lockoutDuration = 900; // 15 minutes

$failedAttempts = $this->getFailedAttempts($username);
if ($failedAttempts >= $maxAttempts) {
    $lastAttempt = $this->getLastAttemptTime($username);
    if (time() - $lastAttempt < $lockoutDuration) {
        throw new Exception('Account temporarily locked');
    }
    $this->resetFailedAttempts($username);
}

Enforce Secure Password Requirements

At minimum, require:

  • 12 characters minimum length
  • No check against common password lists (use the Have I Been Pwned API or a local wordlist)
  • No match against the username or email

HTTP Security Headers

Add these headers to every response, either in a front controller plugin or in your web server configuration:

1
2
3
4
5
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

These are independent of the framework and protect against common attack patterns regardless of your application code quality.

File Upload Security

If your application accepts file uploads through Zend_File_Transfer:

  1. Validate MIME types server-side using finfo_file(), not the client-supplied Content-Type header
  2. Store uploads outside the web root
  3. Generate random filenames instead of using the original filename
  4. Set a maximum file size in both PHP configuration and application code
  5. Scan uploaded files for malware if your infrastructure supports it

Deployment Hardening

Disable Error Display in Production

1
2
3
display_errors = Off
log_errors = On
error_log = /var/log/php/application-errors.log

Detailed error messages in production reveal file paths, database credentials, and stack traces to attackers.

Remove Development Tools

Ensure these are not accessible in production:

  • phpinfo() pages
  • Zend_Debug::dump() calls
  • Database migration scripts with web-accessible entry points
  • The scripts/ directory if it contains CLI tools

Restrict File Permissions

Your web server user should have read-only access to the application code. Only the data/ and tmp/ directories (if they exist) need write access.

Monitoring and Incident Response

Log Security Events

Log authentication failures, CSRF validation failures, input validation failures, and any 403/404 spikes. Use a structured logging format that your monitoring tools can parse.

Set Up Dependency Scanning

Run composer audit regularly. If your application uses zf1-future, subscribe to the fork’s GitHub release notifications. When a security fix drops, update immediately.

FAQ

Is ZF1 inherently insecure?
No more than any other framework of its era. The security issues come from missing modern defaults (no automatic output escaping, no CSRF by default) and from applications that do not use the security features the framework does provide.

Can I add rate limiting without framework changes?
Yes. Implement rate limiting at the web server level (Apache mod_evasive, Nginx limit_req) or via a front controller plugin that checks a Redis counter.

Should I invest in hardening if I plan to migrate eventually?
Yes. Security hardening protects you during the migration period, which could be months or years. The hardening work is also transferable: security headers, password hashing, and input validation patterns apply to whatever framework you migrate to.

Next Steps

Work through this checklist from top to bottom. Start with input validation and SQL injection because they have the highest impact. Session security and CSRF come next. XSS prevention and HTTP headers can be addressed in parallel.

For the PHP runtime side of security, keeping your PHP version current is essential. The Modernising Zend Framework Applications guide covers the broader upgrade path, and the Performance Optimisation chapter covers server-level configuration that also affects security posture.