new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

OWASP Cheat Sheets · all subjects

csrf/custom_headers

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

Subdomain takeover risk with CORS configuration

Do not configure CORS to allow all subdomains using regular expressions (e.g., allowing *.yoursite.com). If an attacker can take over a subdomain via DNS takeover or other means (common with cloud services), they can bypass same-origin policy and forge requests with custom headers. Always explicitly whitelist only the specific subdomains you control.

Custom request headers for CSRF protection in AJAX/API

For AJAX or API endpoints, use custom request headers for CSRF protection instead of form fields or cookies. Client appends custom header to requests requiring CSRF protection. The header can be any arbitrary key-value pair, commonly: X-CSRF-Token (Ruby on Rails, Laravel, Django), X-XSRF-Token (AngularJS), CSRF-Token (Express.js with csurf middleware), X-CSRFToken (Django). Server checks for header existence and rejects requests lacking it. This approach requires no server state and no UI changes. Defense relies on CORS preflight mechanism: browsers designate requests with custom headers as 'to be preflighted', sending OPTIONS request first.

Custom headers and CORS - preventing CSRF

To allow CORS requests with custom headers while preventing CSRF: (1) Do NOT use Access-Control-Allow-Origin=* with credentials; browser rejects responses including both * origin and credentials flag; (2) Instead, whitelist specific origins via Access-Control-Allow-Origin header with Access-Control-Allow-Credentials=true; (3) Only cross-origin requests from allowed domains will be able to set custom headers. Example safe configurations: Access-Control-Allow-Origin=http://mobile.yoursite.com, Access-Control-Allow-Credentials=true OR Access-Control-Allow-Origin=http://www.yoursite.com, Access-Control-Allow-Credentials=true

Give your agent this brain