ஃபிரன்ட்எண்ட் பாதுகாப்பை வலுப்படுத்துதல்: உள்ளடக்கப் பாதுகாப்புக் கொள்கை மற்றும் CORS

இன்றைய ஒன்றோடொன்று இணைக்கப்பட்ட டிஜிட்டல் உலகில், ஃபிரன்ட்எண்ட் பாதுகாப்பு மிக முக்கியமானது. வலைச் செயலிகள் அதிநவீன தாக்குதல்களால் பெருகிய முறையில் குறிவைக்கப்படுகின்றன, இதனால் வலுவான பாதுகாப்பு நடவடிக்கைகள் அவசியமாகின்றன. ஒரு பாதுகாப்பான ஃபிரன்ட்எண்ட் கட்டமைப்பின் இரண்டு முக்கிய கூறுகள் உள்ளடக்கப் பாதுகாப்புக் கொள்கை (Content Security Policy - CSP) மற்றும் கிராஸ்-ஆரிஜின் ரிசோர்ஸ் ஷேரிங் (Cross-Origin Resource Sharing - CORS) ஆகும். இந்த விரிவான வழிகாட்டி, இந்தத் தொழில்நுட்பங்களைப் பற்றிய ஆழமான பார்வையை வழங்குகிறது, மேலும் நவீன அச்சுறுத்தல்களுக்கு எதிராக உங்கள் வலைச் செயலிகளை வலுப்படுத்த உதவும் நடைமுறை எடுத்துக்காட்டுகள் மற்றும் செயல்படுத்தக்கூடிய நுண்ணறிவுகளை வழங்குகிறது.

உள்ளடக்கப் பாதுகாப்புக் கொள்கை (CSP) என்றால் என்ன?

உள்ளடக்கப் பாதுகாப்புக் கொள்கை (CSP) என்பது ஒரு கூடுதல் பாதுகாப்பு அடுக்காகும், இது கிராஸ்-சைட் ஸ்கிரிப்டிங் (XSS) மற்றும் தரவு உட்செலுத்துதல் தாக்குதல்கள் போன்ற சில வகையான தாக்குதல்களைக் கண்டறிந்து தணிக்க உதவுகிறது. CSP, வலை சேவையகம் உலாவிக்கு ஒரு Content-Security-Policy HTTP ரெஸ்பான்ஸ் ஹெடரை அனுப்புவதன் மூலம் செயல்படுத்தப்படுகிறது. இந்த ஹெடர், உலாவி எந்தெந்த மூலங்களிலிருந்து ஆதாரங்களை ஏற்ற அனுமதிக்கப்படுகிறது என்பதை வரையறுக்கும் ஒரு வெள்ளைப் பட்டியலை (whitelist) வரையறுக்கிறது. ஒரு உலாவி ஏற்றக்கூடிய உள்ளடக்கத்தின் மூலங்களைக் கட்டுப்படுத்துவதன் மூலம், தாக்குபவர்கள் உங்கள் இணையதளத்தில் தீங்கிழைக்கும் குறியீட்டை உட்செலுத்துவதை 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: XMLHttpRequest, WebSocket மற்றும் EventSource போன்ற ஸ்கிரிப்ட் இடைமுகங்களைப் பயன்படுத்தி பயனர் முகவர் எந்த URL-களுடன் இணைக்க முடியும் என்பதைக் குறிப்பிடுகிறது.
• base-uri: ஒரு ஆவணத்தின் <base> உறுப்பில் பயன்படுத்தக்கூடிய URL-களைக் குறிப்பிடுகிறது.
• form-action: எந்த URL-களுக்கு படிவ சமர்ப்பிப்புகளை அனுப்பலாம் என்பதைக் குறிப்பிடுகிறது.
• upgrade-insecure-requests: பாதுகாப்பற்ற கோரிக்கைகளை (HTTP) பாதுகாப்பான கோரிக்கைகளாக (HTTPS) தானாக மேம்படுத்துமாறு பயனர் முகவருக்கு அறிவுறுத்துகிறது.
• report-uri: CSP மீறல்கள் பற்றிய அறிக்கைகளை உலாவி அனுப்ப வேண்டிய URL-ஐக் குறிப்பிடுகிறது. இந்த டைரக்டிவ் `report-to`-க்கு ஆதரவாக வழக்கொழிந்துவிட்டது.
• report-to: `Report-To` ஹெடரில் வரையறுக்கப்பட்ட ஒரு புகாரளிக்கும் குழுவின் பெயரைக் குறிப்பிடுகிறது, அங்கு உலாவி CSP மீறல்கள் பற்றிய அறிக்கைகளை அனுப்ப வேண்டும்.

CSP மூலப் பட்டியல் முக்கிய வார்த்தைகள்

CSP டைரக்டிவ்களுக்குள், அனுமதிக்கப்பட்ட மூலங்களை வரையறுக்க மூலப் பட்டியல் முக்கிய வார்த்தைகளைப் பயன்படுத்தலாம். இங்கே சில பொதுவான முக்கிய வார்த்தைகள்:

• 'self': ஆவணத்தின் அதே மூலத்திலிருந்து (ஸ்கீம் மற்றும் ஹோஸ்ட்) ஆதாரங்களை அனுமதிக்கிறது.
• 'none': அனைத்து மூலங்களிலிருந்தும் ஆதாரங்களை அனுமதிக்காது.
• 'unsafe-inline': இன்லைன் ஸ்கிரிப்டுகள் மற்றும் ஸ்டைல்களைப் பயன்படுத்த அனுமதிக்கிறது (எ.கா., <script> குறிச்சொற்கள் மற்றும் ஸ்டைல் பண்புக்கூறுகள்). மிகுந்த எச்சரிக்கையுடன் பயன்படுத்தவும் ஏனெனில் இது XSS-க்கு எதிரான CSP பாதுகாப்பை கணிசமாகக் குறைக்கிறது.
• 'unsafe-eval': eval() மற்றும் Function() போன்ற டைனமிக் குறியீடு மதிப்பீட்டு செயல்பாடுகளைப் பயன்படுத்த அனுமதிக்கிறது. மிகுந்த எச்சரிக்கையுடன் பயன்படுத்தவும் ஏனெனில் இது குறிப்பிடத்தக்க பாதுகாப்பு அபாயங்களை அறிமுகப்படுத்துகிறது.
• 'unsafe-hashes': ஒரு குறிப்பிட்ட ஹாஷுடன் பொருந்தக்கூடிய குறிப்பிட்ட இன்லைன் நிகழ்வு கையாளுபவர்கள் அல்லது <style> குறிச்சொற்களை அனுமதிக்கிறது. உலாவி ஆதரவு தேவை. எச்சரிக்கையுடன் பயன்படுத்தவும்.
• 'strict-dynamic': ஒரு நான்ஸ் அல்லது ஹாஷுடன் மார்க்கப்பில் இருக்கும் ஒரு ஸ்கிரிப்டுக்கு வெளிப்படையாகக் கொடுக்கப்பட்ட நம்பிக்கை, அந்த மூல ஸ்கிரிப்ட்டால் ஏற்றப்பட்ட அனைத்து ஸ்கிரிப்டுகளுக்கும் பரப்பப்பட வேண்டும் என்பதைக் குறிப்பிடுகிறது.
• data: data: URI-களை அனுமதிக்கிறது (எ.கா., பேஸ்64 ஆக குறியிடப்பட்ட இன்லைன் படங்கள்). எச்சரிக்கையுடன் பயன்படுத்தவும்.
• 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) என்பது ஒரு தோற்றத்திலிருந்து (டொமைன்) வரும் வலைப்பக்கங்கள் வேறுபட்ட தோற்றத்திலிருந்து வரும் ஆதாரங்களை அணுக அனுமதிக்கும் ஒரு பொறிமுறையாகும். இயல்பாக, உலாவிகள் ஒரே-தோற்றக் கொள்கையை (Same-Origin Policy) அமல்படுத்துகின்றன, இது ஸ்கிரிப்டுகள் தோன்றிய தோற்றத்திலிருந்து வேறுபட்ட தோற்றத்திற்கு கோரிக்கைகளை வைப்பதைத் தடுக்கிறது. CORS இந்த கட்டுப்பாட்டைத் தேர்ந்தெடுத்து தளர்த்த ஒரு வழியை வழங்குகிறது, இது முறையான கிராஸ்-ஆரிஜின் கோரிக்கைகளை அனுமதிக்கும் அதே வேளையில் தீங்கிழைக்கும் தாக்குதல்களிலிருந்து பாதுகாக்கிறது.

ஒரே-தோற்றக் கொள்கையைப் புரிந்துகொள்ளுதல்

ஒரே-தோற்றக் கொள்கை என்பது ஒரு வலைத்தளத்திலிருந்து வரும் தீங்கிழைக்கும் ஸ்கிரிப்ட் மற்றொரு வலைத்தளத்தில் உள்ள முக்கியமான தரவை அணுகுவதைத் தடுக்கும் ஒரு அடிப்படை பாதுகாப்பு பொறிமுறையாகும். ஒரு தோற்றம் என்பது ஸ்கீம் (நெறிமுறை), ஹோஸ்ட் (டொமைன்) மற்றும் போர்ட் ஆகியவற்றால் வரையறுக்கப்படுகிறது. இரண்டு URL-கள் ஒரே ஸ்கீம், ஹோஸ்ட் மற்றும் போர்ட்டைக் கொண்டிருந்தால் மட்டுமே அவை ஒரே தோற்றத்தைக் கொண்டிருக்கும்.

உதாரணமாக:

• 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
              
            
          

உங்கள் ஜாவாஸ்கிரிப்ட் 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-ஐப் பயன்படுத்தலாம், மேலும் உங்கள் API இறுதிப் புள்ளிகளை எந்தத் தோற்றங்கள் அணுகலாம் என்பதைக் கட்டுப்படுத்த CORS-ஐப் பயன்படுத்தலாம்.

எடுத்துக்காட்டு: 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 தாக்குதல்கள், தரவு உட்செலுத்துதல் தாக்குதல்கள் மற்றும் பிற பாதுகாப்பு பாதிப்புகளின் அபாயத்தை நீங்கள் கணிசமாகக் குறைக்கலாம். ஒரு கட்டுப்படுத்தப்பட்ட கொள்கையுடன் தொடங்கவும், முழுமையாகச் சோதிக்கவும், உங்கள் பயன்பாட்டில் ஏற்படும் மாற்றங்கள் மற்றும் வளர்ந்து வரும் அச்சுறுத்தல் நிலப்பரப்புக்கு ஏற்ப உங்கள் உள்ளமைவைத் தொடர்ந்து கண்காணித்து செம்மைப்படுத்தவும் நினைவில் கொள்ளுங்கள். ஃபிரன்ட்எண்ட் பாதுகாப்பிற்கு முன்னுரிமை அளிப்பதன் மூலம், உங்கள் பயனர்களைப் பாதுகாத்து, இன்றைய பெருகிய முறையில் சிக்கலான டிஜிட்டல் உலகில் உங்கள் வலைச் செயலிகளின் ஒருமைப்பாட்டை உறுதிசெய்யலாம்.