flawopen.com/CSRF/GET अनुरोध
GET के लिए CSRF token कब आवश्यक है?
यदि GET केवल data पढ़ता है, तो उसे server state नहीं बदलनी चाहिए और आम तौर पर CSRF token की जरूरत नहीं होती। Browser, crawler, preview और embedded resource बिना जानबूझकर click के GET भेज सकते हैं। इसलिए delete या purchase जैसी कार्रवाई unsafe method से करें और cookie-authenticated बदलावों को CSRF से बचाएँ। पुराना state-changing GET अभी भी vulnerable है; migrate करने तक अस्थायी सुरक्षा चाहिए।
GET को safe method क्यों रखना चाहिए
RFC 9110 GET को safe बताता है: client state बदलने का अनुरोध नहीं करता। Safe का अर्थ यह नहीं कि server पर logging जैसे incidental effects नहीं होते। GET idempotent भी है, लेकिन यह अलग गुण है। Browser, prefetch, crawler और link preview बिना जानबूझकर user action के safe request भेज सकते हैं। दूसरी site का <img src="..."> भी user cookies के साथ GET भेजवा सकता है। यदि endpoint item delete करे या account setting बदले, तो वह GET semantics तोड़ता है और सामान्य page content उसे trigger कर सकता है।
State-changing requests पर CSRF सुरक्षा लगाएँ
- ✓GET, HEAD और OPTIONS से अनुरोधित state परिवर्तन न करें; mutation के लिए POST, PUT, PATCH या DELETE उपयोग करें
- ✓Cookie-authenticated unsafe methods को framework CSRF सुरक्षा या सत्यापित token से बचाएँ; SameSite और Origin/Fetch Metadata checks को अतिरिक्त परत बनाएँ
- ✓किसी भी state-changing GET को HTTP method semantics की bug मानें; जरूरत पर अस्थायी CSRF सुरक्षा जोड़ें, action migrate करें और URL से secrets हटाएँ
GET पर CSRF के आम सवाल
इसे vulnerable मानें। अस्थायी रूप से server-validated CSRF रक्षा अनिवार्य करें (उदाहरण: synchronizer token और जहाँ उपलब्ध हो Origin या Fetch Metadata checks), cache और Referer का audit करें, फिर action को POST, PUT, PATCH या DELETE में migrate करें। Query string में token न रखें: URL browser history, logs और Referer data में आ सकते हैं। Token check केवल तब तक का उपाय है जब तक endpoint safe-method semantics का पालन न करे।