csrf prevention

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Malicious behavior event: malicious_cors

Log unauthorized cross-origin requests with event name 'malicious_cors:[userid|IP,useragent,referer]' at CRITICAL level. Even blocked requests should be logged as they indicate attack attempts. Note: 'referer' spelling matches original HTTP spec typo. Example: event 'malicious_cors:127.0.0.1,Mozilla/5.0...,attack.evil.com' logs CORS violation from attack origin.

Malicious behavior event: malicious_csrf

Log CSRF attack attempts with event name 'malicious_csrf:[userid|IP]' at WARN level. Log when state-changing requests arrive without valid anti-CSRF token, or with mismatched token, Origin, or Referer header. Example: event 'malicious_csrf:joebob1' logs missing valid anti-CSRF token. See OWASP CSRF Prevention Cheat Sheet for token and Origin/Referer validation guidance.

CSRF prevention with deprecated csurf and alternatives

The `csurf` Express middleware was previously used to mitigate CSRF attacks but has a security vulnerability and is now deprecated. Use alternative CSRF protection packages instead. Refer to the Cross-Site Request Forgery Prevention Cheat Sheet for detailed prevention methods.

Token authentication and CSRF protection relationship

When using only token authentication (no cookies), CSRF protection is not needed in controllers. When both cookies and tokens are used for authentication on different paths, CSRF protection must still be enabled for cookie-authenticated paths.

Rails CSRF protection with protect_from_forgery directive

Enable CSRF protection by including protect_from_forgery in ApplicationController: class ApplicationController < ActionController::Base; protect_from_forgery; end. By default, Rails does not provide CSRF protection for HTTP GET requests. Exceptions can be added with except: :action_name, but must be consciously reviewed.

serverActions.allowedOrigins must be kept narrow

Next.js compares the request Origin with the host for Server Actions. Keep serverActions.allowedOrigins narrow when a trusted proxy requires additional origins. On self-hosted deployment, ensure only trusted infrastructure can establish the canonical Host or X-Forwarded-Host value seen by the application. This built-in Origin check does not replace authentication, authorization, or general CSRF prevention controls.

Restrict serverActions.allowedOrigins

Keep serverActions.allowedOrigins restricted to trusted application and proxy origins.

Give your agent this brain