How to protect against CSRF attacks by verifying the Referer header and what are the limitations?

Verifying the Referer header is a traditional method for protecting against CSRF attacks by checking the HTTP request's Referer header to verify the legitimacy of the request source.

Basic Principles of Referer Header

The Referer header is part of the HTTP request headers and contains the URL of the page that initiated the request. The server can determine whether the request comes from a trusted source by checking the Referer header.

Implementation of Referer Header Verification

Basic Verification Logic

javascript
function validateReferer(req, trustedDomains) {
    const referer = req.headers.referer;
    
    if (!referer) {
        return false; // Reject requests without Referer
    }
    
    try {
        const refererUrl = new URL(referer);
        const refererDomain = refererUrl.hostname;
        
        return trustedDomains.some(domain => 
            refererDomain === domain || refererDomain.endsWith('.' + domain)
        );
    } catch (error) {
        return false; // Invalid URL
    }
}

// Usage example
app.post('/api/transfer', (req, res) => {
    const trustedDomains = ['example.com', 'www.example.com'];
    
    if (!validateReferer(req, trustedDomains)) {
        return res.status(403).send('Invalid referer');
    }
    
    // Handle transfer request
});

Verification Strategies

1. Strict Matching

• Referer must exactly match trusted domains
• Provides strongest security
• May affect some legitimate requests

2. Domain Matching

• Allows subdomains
• More flexible verification
• Need to ensure all subdomains are trusted

3. Allow Empty Referer

• Referer may be empty in some cases (e.g., typing URL directly)
• Need to combine with other verification methods
• Reduces security

Limitations of Referer Header

1. Privacy Settings

• Some browsers or privacy plugins may block sending Referer
• Users can disable Referer header
• Legitimate requests may be rejected

2. Forgery Possibility

• Referer header can be forged by attackers
• Not an absolutely secure protection method
• Need to combine with other protection measures

3. HTTPS Downgrade

• Referer may be removed when initiating HTTP requests from HTTPS pages
• Complex handling in mixed content scenarios

4. Browser Compatibility

• Different browsers may handle Referer differently
• Inconsistent behavior in some mobile browsers

Best Practices

1. Multi-layer Protection

javascript
function csrfProtection(req, res, next) {
    // Verify Referer
    if (!validateReferer(req, trustedDomains)) {
        return res.status(403).send('Invalid referer');
    }
    
    // Verify CSRF Token
    if (req.body._csrf !== req.session.csrfToken) {
        return res.status(403).send('Invalid CSRF token');
    }
    
    next();
}

2. Configure Referer-Policy

html
<meta name="referrer" content="strict-origin-when-cross-origin">

3. Whitelist Management

• Maintain list of trusted domains
• Regularly update and review
• Support dynamic configuration

4. Logging

javascript
if (!validateReferer(req, trustedDomains)) {
    logger.warn('Invalid referer attempt', {
        referer: req.headers.referer,
        ip: req.ip,
        path: req.path
    });
    return res.status(403).send('Invalid referer');
}

Applicable Scenarios

Scenarios Suitable for Referer Verification

• Internal management systems
• API interface protection
• As auxiliary protection measure

Scenarios Not Suitable for Standalone Use

• Public websites
• Systems with extremely high security requirements
• Scenarios requiring support for multiple access methods

Modern Alternatives

With the popularity of SameSite Cookie and CSRF Token, Referer verification is typically used as an auxiliary protection measure rather than the primary protection method.

Although verifying the Referer header has certain limitations, in correct usage scenarios and combined with other protection measures, it can still provide effective CSRF protection.