# Cross-Site Request Forgery (CSRF) (CWE-352) The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request. **Stack:** Python - Prevalence: Medium 3 languages covered - Impact: High 3 high-severity rules - Prevention: Documented 3 fix examples **OWASP:** Broken Access Control (A01:2021-Broken Access Control) - #1 ## Description When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. ## Prevention Prevention strategies for Cross-Site Request Forgery based on 1 Shoulder detection rules. ### Python Ensure CsrfViewMiddleware is enabled and never use @csrf_exempt on state-changing views ## Warning Signs - [HIGH] View handles POST/PUT/DELETE without @csrf_protect or @ensure_csrf_cookie decorator - [HIGH] Django views that handle POST/PUT/DELETE requests without CSRF protection ## Consequences - Modify Application Data - Gain Privileges - Execute Unauthorized Code ## Mitigations - Use anti-CSRF tokens in all state-changing requests - Check the Referer header - Use SameSite cookie attribute ## Detection - Total rules: 3 - Languages: javascript, typescript, python, go ## Rules by Language ### Python (1 rules) - **Django Missing CSRF Protection** [HIGH]: Detects Django views that handle POST/PUT/DELETE requests without CSRF protection. CSRF tokens prevent malicious sites from performing actions on behalf of authenticated users. - Remediation: Add CSRF protection: ```python # Option 1: Use csrf_protect decorator from django.views.decorators.csrf import csrf_protect @csrf_protect def my_view(request): if request.method == 'POST': # Handle POST pass # Option 2: Enable CSRF middleware (recommended) # In settings.py MIDDLEWARE: 'django.middleware.csrf.CsrfViewMiddleware', ```