ફ્રન્ટએન્ડ સુરક્ષાને મજબૂત બનાવવી: કન્ટેન્ટ સિક્યુરિટી પોલિસી અને CORS

આજના એકબીજા સાથે જોડાયેલા ડિજિટલ વિશ્વમાં, ફ્રન્ટએન્ડ સુરક્ષા સર્વોપરી છે. વેબ એપ્લિકેશન્સ પર સતત આધુનિક હુમલાઓનું લક્ષ્ય બનાવવામાં આવે છે, જેના કારણે મજબૂત સુરક્ષા પગલાં અત્યંત જરૂરી છે. સુરક્ષિત ફ્રન્ટએન્ડ આર્કિટેક્ચરના બે મહત્ત્વપૂર્ણ ઘટકો કન્ટેન્ટ સિક્યુરિટી પોલિસી (CSP) અને ક્રોસ-ઓરિજિન રિસોર્સ શેરિંગ (CORS) છે. આ વ્યાપક માર્ગદર્શિકા આ ટેકનોલોજીઓ પર ઊંડાણપૂર્વક દ્રષ્ટિ પૂરી પાડે છે, જેમાં વ્યવહારુ ઉદાહરણો અને કાર્યક્ષમ માહિતીઓ આપવામાં આવી છે જે તમને તમારી વેબ એપ્લિકેશન્સને આધુનિક જોખમો સામે મજબૂત બનાવવામાં મદદ કરશે.

કન્ટેન્ટ સિક્યુરિટી પોલિસી (CSP) શું છે?

કન્ટેન્ટ સિક્યુરિટી પોલિસી (CSP) એ સુરક્ષાનું એક વધારાનું સ્તર છે જે ક્રોસ-સાઇટ સ્ક્રિપ્ટિંગ (XSS) અને ડેટા ઇન્જેક્શન જેવા હુમલાઓને શોધવા અને તેને ઘટાડવામાં મદદ કરે છે. CSP વેબ સર્વર દ્વારા બ્રાઉઝરને Content-Security-Policy HTTP રિસ્પોન્સ હેડર મોકલીને લાગુ કરવામાં આવે છે. આ હેડર એવા સ્રોતોની એક વ્હાઇટલિસ્ટ (માન્ય યાદી) વ્યાખ્યાયિત કરે છે જેમાંથી બ્રાઉઝરને સંસાધનો લોડ કરવાની મંજૂરી છે. બ્રાઉઝર જે કન્ટેન્ટ લોડ કરી શકે છે તેના સ્રોતોને પ્રતિબંધિત કરીને, CSP હુમલાખોરો માટે તમારી વેબસાઇટમાં દૂષિત કોડ દાખલ કરવાનું નોંધપાત્ર રીતે વધુ મુશ્કેલ બનાવે છે.

CSP કેવી રીતે કામ કરે છે

CSP બ્રાઉઝરને ફક્ત માન્ય સ્રોતોમાંથી જ સંસાધનો (દા.ત., સ્ક્રિપ્ટ્સ, સ્ટાઇલશીટ્સ, છબીઓ, ફોન્ટ્સ) લોડ કરવા માટે સૂચના આપીને કામ કરે છે. આ સ્રોતો CSP હેડરમાં ડિરેક્ટિવ્સ (નિર્દેશો) નો ઉપયોગ કરીને સ્પષ્ટ કરવામાં આવે છે. જો બ્રાઉઝર એવા સ્રોતમાંથી સંસાધન લોડ કરવાનો પ્રયાસ કરે છે જેની સ્પષ્ટપણે મંજૂરી નથી, તો તે વિનંતીને અવરોધિત કરશે અને ઉલ્લંઘનની જાણ કરશે.

CSP ડિરેક્ટિવ્સ: એક વ્યાપક અવલોકન

CSP ડિરેક્ટિવ્સ એવા સંસાધનોના પ્રકારોને નિયંત્રિત કરે છે જે ચોક્કસ સ્રોતોમાંથી લોડ કરી શકાય છે. અહીં કેટલાક સૌથી મહત્ત્વપૂર્ણ ડિરેક્ટિવ્સનું વિવરણ છે:

• default-src: બધા કન્ટેન્ટ પ્રકારો માટે ડિફોલ્ટ સ્રોત સ્પષ્ટ કરે છે. આ એક ફોલબેક ડિરેક્ટિવ છે જે ત્યારે લાગુ પડે છે જ્યારે અન્ય, વધુ વિશિષ્ટ ડિરેક્ટિવ્સ હાજર ન હોય.
• script-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી સ્ક્રિપ્ટ્સ લોડ કરી શકાય છે. XSS હુમલાઓને રોકવા માટે આ નિર્ણાયક છે.
• style-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી સ્ટાઇલશીટ્સ લોડ કરી શકાય છે.
• img-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી છબીઓ લોડ કરી શકાય છે.
• font-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી ફોન્ટ્સ લોડ કરી શકાય છે.
• media-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી ઓડિયો અને વિડિયો લોડ કરી શકાય છે.
• object-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી પ્લગઇન્સ (દા.ત., Flash) લોડ કરી શકાય છે. તેમના અંતર્ગત સુરક્ષા જોખમોને કારણે પ્લગઇન્સને સંપૂર્ણપણે અક્ષમ કરવા માટે આ ઘણીવાર 'none' પર સેટ કરવામાં આવે છે.
• frame-src: એવા સ્રોતો સ્પષ્ટ કરે છે જ્યાંથી ફ્રેમ્સ (દા.ત., <iframe>) લોડ કરી શકાય છે.
• connect-src: એવા URLs સ્પષ્ટ કરે છે જેની સાથે યુઝર એજન્ટ XMLHttpRequest, WebSocket અને EventSource જેવા સ્ક્રિપ્ટ ઇન્ટરફેસનો ઉપયોગ કરીને કનેક્ટ કરી શકે છે.
• base-uri: એવા URLs સ્પષ્ટ કરે છે જે દસ્તાવેજના <base> એલિમેન્ટમાં વાપરી શકાય છે.
• form-action: એવા URLs સ્પષ્ટ કરે છે જ્યાં ફોર્મ સબમિશન મોકલી શકાય છે.
• upgrade-insecure-requests: યુઝર એજન્ટને અસુરક્ષિત વિનંતીઓ (HTTP) ને આપમેળે સુરક્ષિત વિનંતીઓ (HTTPS) માં અપગ્રેડ કરવાની સૂચના આપે છે.
• report-uri: એક URL સ્પષ્ટ કરે છે જ્યાં બ્રાઉઝરે CSP ઉલ્લંઘનો વિશે રિપોર્ટ્સ મોકલવા જોઈએ. આ ડિરેક્ટિવ `report-to` ની તરફેણમાં નાપસંદ કરવામાં આવ્યું છે.
• report-to: `Report-To` હેડરમાં વ્યાખ્યાયિત રિપોર્ટિંગ ગ્રુપનું નામ સ્પષ્ટ કરે છે, જ્યાં બ્રાઉઝરે CSP ઉલ્લંઘનો વિશે રિપોર્ટ્સ મોકલવા જોઈએ.

CSP સોર્સ લિસ્ટ કીવર્ડ્સ

CSP ડિરેક્ટિવ્સમાં, તમે માન્ય સ્રોતોને વ્યાખ્યાયિત કરવા માટે સોર્સ લિસ્ટ કીવર્ડ્સનો ઉપયોગ કરી શકો છો. અહીં કેટલાક સામાન્ય કીવર્ડ્સ છે:

• 'self': દસ્તાવેજના સમાન ઓરિજિન (સ્કીમ અને હોસ્ટ) માંથી સંસાધનોને મંજૂરી આપે છે.
• 'none': બધા સ્રોતોમાંથી સંસાધનોને અસ્વીકાર કરે છે.
• 'unsafe-inline': ઇનલાઇન સ્ક્રિપ્ટ્સ અને સ્ટાઇલ્સ (દા.ત., <script> ટૅગ્સ અને style એટ્રિબ્યુટ્સ) ના ઉપયોગની મંજૂરી આપે છે. ખૂબ સાવધાનીથી ઉપયોગ કરો કારણ કે તે XSS સામે CSP સુરક્ષાને નોંધપાત્ર રીતે નબળી પાડે છે.
• 'unsafe-eval': eval() અને Function() જેવા ડાયનેમિક કોડ મૂલ્યાંકન ફંક્શન્સના ઉપયોગની મંજૂરી આપે છે. ખૂબ સાવધાનીથી ઉપયોગ કરો કારણ કે તે નોંધપાત્ર સુરક્ષા જોખમો રજૂ કરે છે.
• 'unsafe-hashes': ચોક્કસ ઇનલાઇન ઇવેન્ટ હેન્ડલર્સ અથવા <style> ટૅગ્સને મંજૂરી આપે છે જે સ્પષ્ટ કરેલ હેશ સાથે મેળ ખાય છે. બ્રાઉઝર સપોર્ટની જરૂર છે. સાવધાનીથી ઉપયોગ કરો.
• 'strict-dynamic': સ્પષ્ટ કરે છે કે માર્કઅપમાં હાજર સ્ક્રિપ્ટને સ્પષ્ટપણે આપવામાં આવેલો વિશ્વાસ, નોન્સ અથવા હેશ સાથે, તે રુટ સ્ક્રિપ્ટ દ્વારા લોડ કરાયેલી બધી સ્ક્રિપ્ટ્સમાં પ્રસારિત થવો જોઈએ.
• data: data: URIs (દા.ત., base64 તરીકે એન્કોડ કરેલી ઇનલાઇન છબીઓ) ને મંજૂરી આપે છે. સાવધાનીથી ઉપયોગ કરો.
• https:: કોઈપણ ડોમેન પરથી HTTPS દ્વારા સંસાધનો લોડ કરવાની મંજૂરી આપે છે.
• [hostname]: ચોક્કસ ડોમેન (દા.ત., example.com) માંથી સંસાધનોને મંજૂરી આપે છે. તમે પોર્ટ નંબર પણ સ્પષ્ટ કરી શકો છો (દા.ત., example.com:8080).
• [scheme]://[hostname]:[port]: એક સંપૂર્ણ ક્વોલિફાઇડ URI, જે સ્પષ્ટ કરેલ સ્કીમ, હોસ્ટ અને પોર્ટ પરથી સંસાધનોને મંજૂરી આપે છે.

CSP ના વ્યવહારુ ઉદાહરણો

ચાલો CSP હેડર્સના કેટલાક વ્યવહારુ ઉદાહરણો જોઈએ:

ઉદાહરણ 1: 'self' સાથે મૂળભૂત CSP

આ પોલિસી ફક્ત સમાન ઓરિજિનમાંથી સંસાધનોને મંજૂરી આપે છે:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

ઉદાહરણ 2: ચોક્કસ ડોમેનમાંથી સ્ક્રિપ્ટ્સને મંજૂરી આપવી

આ પોલિસી તમારા પોતાના ડોમેન અને એક વિશ્વસનીય CDN માંથી સ્ક્રિપ્ટ્સને મંજૂરી આપે છે:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

ઉદાહરણ 3: ઇનલાઇન સ્ક્રિપ્ટ્સ અને સ્ટાઇલ્સને અક્ષમ કરવી

આ પોલિસી ઇનલાઇન સ્ક્રિપ્ટ્સ અને સ્ટાઇલ્સને અસ્વીકાર કરે છે, જે XSS સામે એક મજબૂત બચાવ છે:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

મહત્ત્વપૂર્ણ: ઇનલાઇન સ્ક્રિપ્ટ્સને અક્ષમ કરવા માટે તમારા HTML ને રિફેક્ટર કરવાની જરૂર છે જેથી ઇનલાઇન સ્ક્રિપ્ટ્સને બાહ્ય ફાઇલોમાં ખસેડી શકાય.

ઉદાહરણ 4: ઇનલાઇન સ્ક્રિપ્ટ્સ માટે નોન્સનો ઉપયોગ કરવો

જો તમારે ઇનલાઇન સ્ક્રિપ્ટ્સનો ઉપયોગ કરવો જ પડે, તો ચોક્કસ ઇનલાઇન સ્ક્રિપ્ટ બ્લોક્સને વ્હાઇટલિસ્ટ કરવા માટે નોન્સ (ક્રિપ્ટોગ્રાફિકલી રેન્ડમ, સિંગલ-યુઝ ટોકન્સ) નો ઉપયોગ કરો. આ 'unsafe-inline' કરતાં વધુ સુરક્ષિત છે. સર્વરે દરેક વિનંતી માટે એક અનન્ય નોન્સ જનરેટ કરવો જોઈએ અને તેને CSP હેડર અને <script> ટૅગ બંનેમાં શામેલ કરવો જોઈએ.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

નોંધ: દરેક વિનંતી માટે નવો નોન્સ જનરેટ કરવાનું યાદ રાખો. નોન્સનો ફરીથી ઉપયોગ કરશો નહીં!

ઉદાહરણ 5: ઇનલાઇન સ્ટાઇલ્સ માટે હેશનો ઉપયોગ કરવો

નોન્સની જેમ, હેશનો ઉપયોગ ચોક્કસ ઇનલાઇન <style> બ્લોક્સને વ્હાઇટલિસ્ટ કરવા માટે થઈ શકે છે. આ સ્ટાઇલ કન્ટેન્ટનો SHA256, SHA384, અથવા SHA512 હેશ જનરેટ કરીને કરવામાં આવે છે.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

નોંધ: હેશ નોન્સ કરતાં ઓછા લવચીક હોય છે કારણ કે સ્ટાઇલ કન્ટેન્ટમાં કોઈપણ ફેરફાર હેશને અમાન્ય કરી દેશે.

ઉદાહરણ 6: CSP ઉલ્લંઘનોની જાણ કરવી

CSP ઉલ્લંઘનોનું નિરીક્ષણ કરવા માટે, report-uri અથવા report-to ડિરેક્ટિવનો ઉપયોગ કરો:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

તમારે Report-To હેડરને પણ કન્ફિગર કરવાની જરૂર પડશે. Report-To હેડર એક અથવા વધુ રિપોર્ટિંગ ગ્રુપ્સને વ્યાખ્યાયિત કરે છે, જે સ્પષ્ટ કરે છે કે રિપોર્ટ્સ ક્યાં અને કેવી રીતે મોકલવા જોઈએ.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

CSPનું પરીક્ષણ અને જમાવટ

CSP લાગુ કરવા માટે સાવચેતીપૂર્વક આયોજન અને પરીક્ષણની જરૂર છે. એક પ્રતિબંધિત પોલિસીથી શરૂઆત કરો અને જરૂર મુજબ ધીમે ધીમે તેને હળવી કરો. સંસાધનોને અવરોધિત કર્યા વિના તમારી પોલિસીનું પરીક્ષણ કરવા માટે Content-Security-Policy-Report-Only હેડરનો ઉપયોગ કરો. આ હેડર પોલિસી લાગુ કર્યા વિના ઉલ્લંઘનોની જાણ કરે છે, જે તમને પ્રોડક્શનમાં પોલિસી જમાવતા પહેલા સમસ્યાઓ ઓળખવા અને સુધારવામાં મદદ કરે છે.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

કોઈપણ ઉલ્લંઘનોને ઓળખવા માટે બ્રાઉઝર દ્વારા જનરેટ કરાયેલા રિપોર્ટ્સનું વિશ્લેષણ કરો અને તે મુજબ તમારી પોલિસીને સમાયોજિત કરો. એકવાર તમને વિશ્વાસ થઈ જાય કે તમારી પોલિસી યોગ્ય રીતે કામ કરી રહી છે, ત્યારે તેને Content-Security-Policy હેડરનો ઉપયોગ કરીને જમાવો.

CSP માટેની શ્રેષ્ઠ પદ્ધતિઓ

• default-src થી શરૂઆત કરો: બેઝલાઇન પોલિસી સ્થાપિત કરવા માટે હંમેશા default-src વ્યાખ્યાયિત કરો.
• વિશિષ્ટ બનો: તમારી પોલિસીના વ્યાપને મર્યાદિત કરવા માટે વિશિષ્ટ ડિરેક્ટિવ્સ અને સોર્સ લિસ્ટ કીવર્ડ્સનો ઉપયોગ કરો.
• 'unsafe-inline' અને 'unsafe-eval' ટાળો: આ કીવર્ડ્સ CSP ને નોંધપાત્ર રીતે નબળું પાડે છે અને શક્ય હોય ત્યાં સુધી તેને ટાળવા જોઈએ.
• ઇનલાઇન સ્ક્રિપ્ટ્સ અને સ્ટાઇલ્સ માટે નોન્સ અથવા હેશનો ઉપયોગ કરો: જો તમારે ઇનલાઇન સ્ક્રિપ્ટ્સ અથવા સ્ટાઇલ્સનો ઉપયોગ કરવો જ પડે, તો ચોક્કસ કોડ બ્લોક્સને વ્હાઇટલિસ્ટ કરવા માટે નોન્સ અથવા હેશનો ઉપયોગ કરો.
• CSP ઉલ્લંઘનોનું નિરીક્ષણ કરો: CSP ઉલ્લંઘનોનું નિરીક્ષણ કરવા અને તે મુજબ તમારી પોલિસીને સમાયોજિત કરવા માટે report-uri અથવા report-to ડિરેક્ટિવનો ઉપયોગ કરો.
• સંપૂર્ણ પરીક્ષણ કરો: પ્રોડક્શનમાં જમાવતા પહેલા તમારી પોલિસીનું પરીક્ષણ કરવા માટે Content-Security-Policy-Report-Only હેડરનો ઉપયોગ કરો.
• પુનરાવર્તન અને સુધારો: CSP એ એક-વખતનું રૂપરેખાંકન નથી. તમારી એપ્લિકેશન અને જોખમના વાતાવરણમાં ફેરફારોને અનુકૂળ થવા માટે તમારી પોલિસીનું સતત નિરીક્ષણ અને સુધારો કરો.

ક્રોસ-ઓરિજિન રિસોર્સ શેરિંગ (CORS) શું છે?

ક્રોસ-ઓરિજિન રિસોર્સ શેરિંગ (CORS) એ એક એવી પદ્ધતિ છે જે એક ઓરિજિન (ડોમેન) ના વેબ પેજને બીજા ઓરિજિનમાંથી સંસાધનો એક્સેસ કરવાની મંજૂરી આપે છે. ડિફોલ્ટ રૂપે, બ્રાઉઝર્સ સેમ-ઓરિજિન પોલિસી લાગુ કરે છે, જે સ્ક્રિપ્ટ્સને તે ઓરિજિન કરતાં અલગ ઓરિજિન પર વિનંતીઓ કરવાથી રોકે છે જ્યાંથી સ્ક્રિપ્ટ ઉદ્ભવી છે. CORS આ પ્રતિબંધને પસંદગીયુક્ત રીતે હળવો કરવાનો એક માર્ગ પૂરો પાડે છે, જે કાયદેસર ક્રોસ-ઓરિજિન વિનંતીઓને મંજૂરી આપે છે જ્યારે દૂષિત હુમલાઓ સામે રક્ષણ આપે છે.

સેમ-ઓરિજિન પોલિસીને સમજવી

સેમ-ઓરિજિન પોલિસી એ એક મૂળભૂત સુરક્ષા પદ્ધતિ છે જે એક વેબસાઇટમાંથી દૂષિત સ્ક્રિપ્ટને બીજી વેબસાઇટ પરના સંવેદનશીલ ડેટાને એક્સેસ કરવાથી રોકે છે. એક ઓરિજિન સ્કીમ (પ્રોટોકોલ), હોસ્ટ (ડોમેન) અને પોર્ટ દ્વારા વ્યાખ્યાયિત થયેલ છે. બે URLs સમાન ઓરિજિન ધરાવે છે જો અને માત્ર જો તેમની સ્કીમ, હોસ્ટ અને પોર્ટ સમાન હોય.

ઉદાહરણ તરીકે:

• https://www.example.com/app1/index.html અને https://www.example.com/app2/index.html સમાન ઓરિજિન ધરાવે છે.
• https://www.example.com/index.html અને http://www.example.com/index.html અલગ ઓરિજિન ધરાવે છે (અલગ સ્કીમ).
• https://www.example.com/index.html અને https://sub.example.com/index.html અલગ ઓરિજિન ધરાવે છે (અલગ હોસ્ટ).
• https://www.example.com:8080/index.html અને https://www.example.com:80/index.html અલગ ઓરિજિન ધરાવે છે (અલગ પોર્ટ).

CORS કેવી રીતે કામ કરે છે

જ્યારે વેબ પેજ ક્રોસ-ઓરિજિન વિનંતી કરે છે, ત્યારે બ્રાઉઝર પહેલા સર્વરને "પ્રીફ્લાઇટ" વિનંતી મોકલે છે. પ્રીફ્લાઇટ વિનંતી HTTP OPTIONS મેથડનો ઉપયોગ કરે છે અને તેમાં એવા હેડર્સ શામેલ હોય છે જે વાસ્તવિક વિનંતી કઈ HTTP મેથડ અને હેડર્સનો ઉપયોગ કરશે તે દર્શાવે છે. પછી સર્વર એવા હેડર્સ સાથે જવાબ આપે છે જે દર્શાવે છે કે ક્રોસ-ઓરિજિન વિનંતીને મંજૂરી છે કે નહીં.

જો સર્વર વિનંતીને મંજૂરી આપે છે, તો તે જવાબમાં Access-Control-Allow-Origin હેડર શામેલ કરે છે. આ હેડર એ ઓરિજિન(ઓ) ને સ્પષ્ટ કરે છે જેને સંસાધન એક્સેસ કરવાની મંજૂરી છે. પછી બ્રાઉઝર વાસ્તવિક વિનંતી સાથે આગળ વધે છે. જો સર્વર વિનંતીને મંજૂરી આપતું નથી, તો તે Access-Control-Allow-Origin હેડર શામેલ કરતું નથી, અને બ્રાઉઝર વિનંતીને અવરોધિત કરે છે.

CORS હેડર્સ: એક વિગતવાર દ્રષ્ટિ

CORS બ્રાઉઝર અને સર્વર વચ્ચે સંચાર માટે HTTP હેડર્સ પર આધાર રાખે છે. અહીં મુખ્ય CORS હેડર્સ છે:

• Access-Control-Allow-Origin: એ ઓરિજિન(ઓ) ને સ્પષ્ટ કરે છે જેને સંસાધન એક્સેસ કરવાની મંજૂરી છે. આ હેડરમાં ચોક્કસ ઓરિજિન (દા.ત., https://www.example.com), વાઇલ્ડકાર્ડ (*), અથવા null હોઈ શકે છે. * નો ઉપયોગ કોઈપણ ઓરિજિનમાંથી વિનંતીઓને મંજૂરી આપે છે, જે સામાન્ય રીતે સુરક્ષાના કારણોસર ભલામણ કરાતું નથી. `null` નો ઉપયોગ ફક્ત "અપારદર્શક જવાબો" માટે યોગ્ય છે જેમ કે જ્યારે સંસાધન `file://` પ્રોટોકોલ અથવા ડેટા URI નો ઉપયોગ કરીને પુનઃપ્રાપ્ત કરવામાં આવે છે.
• Access-Control-Allow-Methods: ક્રોસ-ઓરિજિન વિનંતી માટે માન્ય HTTP મેથડ્સ (દા.ત., GET, POST, PUT, DELETE) સ્પષ્ટ કરે છે.
• Access-Control-Allow-Headers: ક્રોસ-ઓરિજિન વિનંતીમાં માન્ય HTTP હેડર્સ સ્પષ્ટ કરે છે. કસ્ટમ હેડર્સને હેન્ડલ કરવા માટે આ મહત્ત્વપૂર્ણ છે.
• Access-Control-Allow-Credentials: સૂચવે છે કે બ્રાઉઝરે ક્રોસ-ઓરિજિન વિનંતીમાં ક્રેડેન્શિયલ્સ (દા.ત., કૂકીઝ, ઓથોરાઇઝેશન હેડર્સ) શામેલ કરવા જોઈએ કે નહીં. ક્રેડેન્શિયલ્સને મંજૂરી આપવા માટે આ હેડરને true પર સેટ કરવું આવશ્યક છે.
• Access-Control-Expose-Headers: સ્પષ્ટ કરે છે કે કયા હેડર્સ ક્લાયન્ટને એક્સપોઝ કરી શકાય છે. ડિફોલ્ટ રૂપે, ફક્ત મર્યાદિત હેડર્સ જ એક્સપોઝ થાય છે.
• Access-Control-Max-Age: બ્રાઉઝર પ્રીફ્લાઇટ વિનંતીને કેટલા સમય સુધી (સેકન્ડમાં) કેશ કરી શકે છે તે મહત્તમ સમય સ્પષ્ટ કરે છે.
• Origin: આ બ્રાઉઝર દ્વારા મોકલાયેલ એક રિક્વેસ્ટ હેડર છે જે વિનંતીના ઓરિજિનને સૂચવે છે.
• Vary: એક સામાન્ય HTTP હેડર, પરંતુ CORS માટે મહત્ત્વપૂર્ણ છે. જ્યારે `Access-Control-Allow-Origin` ગતિશીલ રીતે જનરેટ થાય છે, ત્યારે `Vary: Origin` હેડરને જવાબમાં શામેલ કરવો જોઈએ જેથી કેશિંગ મિકેનિઝમ્સને સૂચના આપી શકાય કે જવાબ `Origin` રિક્વેસ્ટ હેડરના આધારે બદલાય છે.

CORS ના વ્યવહારુ ઉદાહરણો

ચાલો CORS રૂપરેખાંકનોના કેટલાક વ્યવહારુ ઉદાહરણો જોઈએ:

ઉદાહરણ 1: ચોક્કસ ઓરિજિનમાંથી વિનંતીઓને મંજૂરી આપવી

આ રૂપરેખાંકન ફક્ત https://www.example.com માંથી વિનંતીઓને મંજૂરી આપે છે:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

ઉદાહરણ 2: કોઈપણ ઓરિજિનમાંથી વિનંતીઓને મંજૂરી આપવી (ભલામણપાત્ર નથી)

આ રૂપરેખાંકન કોઈપણ ઓરિજિનમાંથી વિનંતીઓને મંજૂરી આપે છે. સાવધાનીથી ઉપયોગ કરો કારણ કે તે સુરક્ષા જોખમો રજૂ કરી શકે છે:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

ઉદાહરણ 3: ચોક્કસ મેથડ્સ અને હેડર્સને મંજૂરી આપવી

આ રૂપરેખાંકન GET, POST, અને PUT મેથડ્સ, અને Content-Type અને Authorization હેડર્સને મંજૂરી આપે છે:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

ઉદાહરણ 4: ક્રેડેન્શિયલ્સને મંજૂરી આપવી

ક્રેડેન્શિયલ્સ (દા.ત., કૂકીઝ) ને મંજૂરી આપવા માટે, તમારે Access-Control-Allow-Credentials ને true પર સેટ કરવાની અને એક ચોક્કસ ઓરિજિન સ્પષ્ટ કરવાની જરૂર છે (ક્રેડેન્શિયલ્સને મંજૂરી આપતી વખતે તમે * નો ઉપયોગ કરી શકતા નથી):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

તમારે તમારી JavaScript fetch/XMLHttpRequest વિનંતીમાં credentials: 'include' પણ સેટ કરવાની જરૂર છે.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

CORS પ્રીફ્લાઇટ વિનંતીઓ

ચોક્કસ પ્રકારની ક્રોસ-ઓરિજિન વિનંતીઓ માટે (દા.ત., કસ્ટમ હેડર્સ અથવા GET, HEAD, અથવા POST સિવાયની મેથડ્સ સાથેની વિનંતીઓ, જેમાં Content-Type application/x-www-form-urlencoded, multipart/form-data, અથવા text/plain હોય છે), બ્રાઉઝર OPTIONS મેથડનો ઉપયોગ કરીને પ્રીફ્લાઇટ વિનંતી મોકલે છે. સર્વરે પ્રીફ્લાઇટ વિનંતીનો યોગ્ય CORS હેડર્સ સાથે જવાબ આપવો જોઈએ જેથી સૂચવી શકાય કે વાસ્તવિક વિનંતીને મંજૂરી છે કે નહીં.

અહીં પ્રીફ્લાઇટ વિનંતી અને જવાબનું એક ઉદાહરણ છે:

પ્રીફ્લાઇટ વિનંતી (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

પ્રીફ્લાઇટ જવાબ (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Access-Control-Max-Age હેડર સ્પષ્ટ કરે છે કે બ્રાઉઝર પ્રીફ્લાઇટ જવાબને કેટલા સમય સુધી કેશ કરી શકે છે, જે પ્રીફ્લાઇટ વિનંતીઓની સંખ્યા ઘટાડે છે.

CORS અને JSONP

JSON with Padding (JSONP) એ સેમ-ઓરિજિન પોલિસીને બાયપાસ કરવા માટેની એક જૂની ટેકનિક છે. જો કે, JSONP માં નોંધપાત્ર સુરક્ષા જોખમો છે અને તેને CORS ની તરફેણમાં ટાળવું જોઈએ. JSONP પેજમાં <script> ટૅગ્સ ઇન્જેક્ટ કરવા પર આધાર રાખે છે, જે મનસ્વી કોડ એક્ઝિક્યુટ કરી શકે છે. CORS ક્રોસ-ઓરિજિન વિનંતીઓને હેન્ડલ કરવા માટે વધુ સુરક્ષિત અને લવચીક માર્ગ પૂરો પાડે છે.

CORS માટેની શ્રેષ્ઠ પદ્ધતિઓ

• * નો ઉપયોગ ટાળો: Access-Control-Allow-Origin હેડરમાં વાઇલ્ડકાર્ડ (*) નો ઉપયોગ ટાળો, કારણ કે તે કોઈપણ ઓરિજિનમાંથી વિનંતીઓને મંજૂરી આપે છે. તેના બદલે, ચોક્કસ ઓરિજિન(ઓ) સ્પષ્ટ કરો જેને સંસાધન એક્સેસ કરવાની મંજૂરી છે.
• મેથડ્સ અને હેડર્સ સાથે વિશિષ્ટ બનો: Access-Control-Allow-Methods અને Access-Control-Allow-Headers હેડર્સમાં માન્ય HTTP મેથડ્સ અને હેડર્સ સ્પષ્ટ કરો.
• Access-Control-Allow-Credentials નો સાવધાનીથી ઉપયોગ કરો: ફક્ત ત્યારે જ Access-Control-Allow-Credentials સક્ષમ કરો જો તમારે ક્રોસ-ઓરિજિન વિનંતીઓમાં ક્રેડેન્શિયલ્સ (દા.ત., કૂકીઝ) ને મંજૂરી આપવાની જરૂર હોય. ક્રેડેન્શિયલ્સને મંજૂરી આપવાના સુરક્ષા પરિણામોથી વાકેફ રહો.
• તમારી પ્રીફ્લાઇટ વિનંતીઓને સુરક્ષિત કરો: ખાતરી કરો કે તમારું સર્વર પ્રીફ્લાઇટ વિનંતીઓને યોગ્ય રીતે હેન્ડલ કરે છે અને સાચા CORS હેડર્સ પરત કરે છે.
• HTTPS નો ઉપયોગ કરો: ઓરિજિન અને તમે ક્રોસ-ઓરિજિન એક્સેસ કરી રહ્યા છો તે સંસાધનો બંને માટે હંમેશા HTTPS નો ઉપયોગ કરો. આ મેન-ઇન-ધ-મિડલ હુમલાઓ સામે રક્ષણ કરવામાં મદદ કરે છે.
• Vary: Origin: જો તમે ગતિશીલ રીતે `Access-Control-Allow-Origin` હેડર જનરેટ કરી રહ્યા છો, તો કેશિંગ સમસ્યાઓ ટાળવા માટે હંમેશા `Vary: Origin` હેડર શામેલ કરો.

CSP અને CORS વ્યવહારમાં: એક સંયુક્ત અભિગમ

જ્યારે CSP અને CORS બંને સુરક્ષા ચિંતાઓને સંબોધિત કરે છે, ત્યારે તેઓ અલગ-અલગ સ્તરો પર કાર્ય કરે છે અને પૂરક સુરક્ષા પ્રદાન કરે છે. CSP બ્રાઉઝરને દૂષિત કન્ટેન્ટ લોડ કરવાથી રોકવા પર ધ્યાન કેન્દ્રિત કરે છે, જ્યારે CORS એ નિયંત્રિત કરવા પર ધ્યાન કેન્દ્રિત કરે છે કે કયા ઓરિજિન તમારા સર્વર પરના સંસાધનોને એક્સેસ કરી શકે છે.

CSP અને CORS ને જોડીને, તમે તમારી વેબ એપ્લિકેશન્સ માટે વધુ મજબૂત સુરક્ષા સ્થિતિ બનાવી શકો છો. ઉદાહરણ તરીકે, તમે CSP નો ઉપયોગ એવા સ્રોતોને પ્રતિબંધિત કરવા માટે કરી શકો છો જ્યાંથી સ્ક્રિપ્ટ્સ લોડ કરી શકાય છે, અને CORS નો ઉપયોગ એ નિયંત્રિત કરવા માટે કરી શકો છો કે કયા ઓરિજિન તમારા API એન્ડપોઇન્ટ્સને એક્સેસ કરી શકે છે.

ઉદાહરણ: CSP અને CORS વડે API સુરક્ષિત કરવું

ધારો કે તમારી પાસે https://api.example.com પર હોસ્ટ કરેલ એક API છે જેને તમે ફક્ત https://www.example.com પરથી જ એક્સેસ કરી શકાય તેવું બનાવવા માંગો છો. તમે તમારા સર્વરને નીચેના હેડર્સ પરત કરવા માટે કન્ફિગર કરી શકો છો:

API રિસ્પોન્સ હેડર્સ (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

અને તમે તમારી વેબસાઇટ (https://www.example.com) ને નીચેના CSP હેડરનો ઉપયોગ કરવા માટે કન્ફિગર કરી શકો છો:

વેબસાઇટ CSP હેડર (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

આ CSP પોલિસી વેબસાઇટને સ્ક્રિપ્ટ્સ લોડ કરવા અને API સાથે કનેક્ટ થવાની મંજૂરી આપે છે, પરંતુ તેને અન્ય ડોમેન્સ પરથી સ્ક્રિપ્ટ્સ લોડ કરવા અથવા કનેક્ટ થવાથી રોકે છે.

નિષ્કર્ષ

કન્ટેન્ટ સિક્યુરિટી પોલિસી (CSP) અને ક્રોસ-ઓરિજિન રિસોર્સ શેરિંગ (CORS) એ તમારી ફ્રન્ટએન્ડ એપ્લિકેશન્સની સુરક્ષાને મજબૂત બનાવવા માટેના આવશ્યક સાધનો છે. CSP અને CORS ને સાવધાનીપૂર્વક કન્ફિગર કરીને, તમે XSS હુમલાઓ, ડેટા ઇન્જેક્શન હુમલાઓ અને અન્ય સુરક્ષા નબળાઈઓના જોખમને નોંધપાત્ર રીતે ઘટાડી શકો છો. પ્રતિબંધિત પોલિસીથી શરૂઆત કરવાનું યાદ રાખો, સંપૂર્ણ પરીક્ષણ કરો, અને તમારી એપ્લિકેશન અને વિકસતા જોખમના વાતાવરણમાં ફેરફારોને અનુકૂળ થવા માટે તમારા રૂપરેખાંકનનું સતત નિરીક્ષણ અને સુધારો કરો. ફ્રન્ટએન્ડ સુરક્ષાને પ્રાથમિકતા આપીને, તમે તમારા વપરાશકર્તાઓને સુરક્ષિત રાખી શકો છો અને આજના વધુને વધુ જટિલ ડિજિટલ વિશ્વમાં તમારી વેબ એપ્લિકેશન્સની અખંડિતતા સુનિશ્ચિત કરી શકો છો.