ಫ್ರಂಟ್‌ಎಂಡ್ ಸೆಕ್ಯುರಿಟಿ ಹಾರ್ಡನಿಂಗ್: ಕಂಟೆಂಟ್ ಸೆಕ್ಯುರಿಟಿ ಪಾಲಿಸಿ ಮತ್ತು CORS

ಇಂದಿನ ಅಂತರ್‌ಸಂಪರ್ಕಿತ ಡಿಜಿಟಲ್ ಜಗತ್ತಿನಲ್ಲಿ, ಫ್ರಂಟ್‌ಎಂಡ್ ಭದ್ರತೆ ಅತ್ಯಂತ ಮಹತ್ವದ್ದಾಗಿದೆ. ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೆಚ್ಚು ಸುಧಾರಿತ ದಾಳಿಗಳಿಗೆ ಗುರಿಯಾಗುತ್ತಿವೆ, ಆದ್ದರಿಂದ ದೃಢವಾದ ಭದ್ರತಾ ಕ್ರಮಗಳು ಅತ್ಯಗತ್ಯ. ಸುರಕ್ಷಿತ ಫ್ರಂಟ್‌ಎಂಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಎರಡು ನಿರ್ಣಾಯಕ ಅಂಶಗಳೆಂದರೆ ಕಂಟೆಂಟ್ ಸೆಕ್ಯುರಿಟಿ ಪಾಲಿಸಿ (CSP) ಮತ್ತು ಕ್ರಾಸ್-ಆರಿಜಿನ್ ರಿಸೋರ್ಸ್ ಶೇರಿಂಗ್ (CORS). ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿಯು ಈ ತಂತ್ರಜ್ಞಾನಗಳ ಬಗ್ಗೆ ಆಳವಾದ ನೋಟವನ್ನು ನೀಡುತ್ತದೆ, ಆಧುನಿಕ ಬೆದರಿಕೆಗಳ ವಿರುದ್ಧ ನಿಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಲಪಡಿಸಲು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳು ಮತ್ತು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಒಳನೋಟಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಕಂಟೆಂಟ್ ಸೆಕ್ಯುರಿಟಿ ಪಾಲಿಸಿ (CSP) ಎಂದರೇನು?

ಕಂಟೆಂಟ್ ಸೆಕ್ಯುರಿಟಿ ಪಾಲಿಸಿ (CSP) ಒಂದು ಹೆಚ್ಚುವರಿ ಭದ್ರತಾ ಪದರವಾಗಿದ್ದು, ಇದು ಕ್ರಾಸ್-ಸೈಟ್ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ (XSS) ಮತ್ತು ಡೇಟಾ ಇಂಜೆಕ್ಷನ್ ದಾಳಿಗಳಂತಹ ಕೆಲವು ರೀತಿಯ ದಾಳಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ತಗ್ಗಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ವೆಬ್ ಸರ್ವರ್ ಬ್ರೌಸರ್‌ಗೆ Content-Security-Policy HTTP ರೆಸ್ಪಾನ್ಸ್ ಹೆಡರ್ ಅನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ CSPಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಈ ಹೆಡರ್ ಬ್ರೌಸರ್‌ಗೆ ಯಾವ ಮೂಲಗಳಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಲೋಡ್ ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಮೂಲಗಳ ವೈಟ್‌ಲಿಸ್ಟ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಬ್ರೌಸರ್ ಲೋಡ್ ಮಾಡಬಹುದಾದ ವಿಷಯದ ಮೂಲಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವ ಮೂಲಕ, CSPಯು ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ಗೆ ದುರುದ್ದೇಶಪೂರಿತ ಕೋಡ್ ಅನ್ನು ಸೇರಿಸುವುದನ್ನು ದಾಳಿಕೋರರಿಗೆ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ.

CSP ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

CSPಯು ಬ್ರೌಸರ್‌ಗೆ ಅನುಮೋದಿತ ಮೂಲಗಳಿಂದ ಮಾತ್ರ ಸಂಪನ್ಮೂಲಗಳನ್ನು (ಉದಾ., ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳು, ಚಿತ್ರಗಳು, ಫಾಂಟ್‌ಗಳು) ಲೋಡ್ ಮಾಡಲು ಸೂಚಿಸುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಮೂಲಗಳನ್ನು CSP ಹೆಡರ್‌ನಲ್ಲಿ ಡೈರೆಕ್ಟಿವ್‌ಗಳನ್ನು ಬಳಸಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ ಬ್ರೌಸರ್ ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಸದ ಮೂಲದಿಂದ ಸಂಪನ್ಮೂಲವನ್ನು ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಅದು ವಿನಂತಿಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಉಲ್ಲಂಘನೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.

CSP ಡೈರೆಕ್ಟಿವ್‌ಗಳು: ಒಂದು ಸಮಗ್ರ ಅವಲೋಕನ

CSP ಡೈರೆಕ್ಟಿವ್‌ಗಳು ನಿರ್ದಿಷ್ಟ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದಾದ ಸಂಪನ್ಮೂಲಗಳ ಪ್ರಕಾರಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. ಇಲ್ಲಿ ಕೆಲವು ಪ್ರಮುಖ ಡೈರೆಕ್ಟಿವ್‌ಗಳ ವಿವರಣೆ ನೀಡಲಾಗಿದೆ:

• default-src: ಎಲ್ಲಾ ವಿಷಯ ಪ್ರಕಾರಗಳಿಗೆ ಡೀಫಾಲ್ಟ್ ಮೂಲವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಇದು ಇತರ, ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದ ಡೈರೆಕ್ಟಿವ್‌ಗಳು ಇಲ್ಲದಿದ್ದಾಗ ಅನ್ವಯವಾಗುವ ಫಾಲ್‌ಬ್ಯಾಕ್ ಡೈರೆಕ್ಟಿವ್ ಆಗಿದೆ.
• script-src: ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಯಾವ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. XSS ದಾಳಿಗಳನ್ನು ತಡೆಯಲು ಇದು ನಿರ್ಣಾಯಕವಾಗಿದೆ.
• style-src: ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳನ್ನು ಯಾವ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• img-src: ಚಿತ್ರಗಳನ್ನು ಯಾವ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• font-src: ಫಾಂಟ್‌ಗಳನ್ನು ಯಾವ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• media-src: ಆಡಿಯೋ ಮತ್ತು ವೀಡಿಯೊವನ್ನು ಯಾವ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• object-src: ಪ್ಲಗಿನ್‌ಗಳನ್ನು (ಉದಾ., ಫ್ಲ್ಯಾಶ್) ಯಾವ ಮೂಲಗಳಿಂದ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಪ್ಲಗಿನ್‌ಗಳ ಅಂತರ್ಗತ ಭದ್ರತಾ ಅಪಾಯಗಳಿಂದಾಗಿ ಇದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಇದನ್ನು ಹೆಚ್ಚಾಗಿ '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 ಗಳನ್ನು (ಉದಾ., 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) ಒಂದು ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯಾಗಿದ್ದು, ಇದು ಒಂದು ಮೂಲದಿಂದ (ಡೊಮೇನ್) ವೆಬ್ ಪುಟಗಳಿಗೆ ಬೇರೆ ಮೂಲದಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಬ್ರೌಸರ್‌ಗಳು ಒಂದೇ-ಮೂಲದ ನೀತಿಯನ್ನು (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 ದಾಳಿಗಳು, ಡೇಟಾ ಇಂಜೆಕ್ಷನ್ ದಾಳಿಗಳು, ಮತ್ತು ಇತರ ಭದ್ರತಾ ದೋಷಗಳ ಅಪಾಯವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು. ನಿರ್ಬಂಧಿತ ಪಾಲಿಸಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು, ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಲು, ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳು ಮತ್ತು ವಿಕಸಿಸುತ್ತಿರುವ ಬೆದರಿಕೆಗಳ ಭೂದೃಶ್ಯಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳಲು ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮತ್ತು ಪರಿಷ್ಕರಿಸಲು ಮರೆಯದಿರಿ. ಫ್ರಂಟ್‌ಎಂಡ್ ಭದ್ರತೆಗೆ ಆದ್ಯತೆ ನೀಡುವ ಮೂಲಕ, ನೀವು ನಿಮ್ಮ ಬಳಕೆದಾರರನ್ನು ರಕ್ಷಿಸಬಹುದು ಮತ್ತು ಇಂದಿನ ಹೆಚ್ಚುತ್ತಿರುವ ಸಂಕೀರ್ಣ ಡಿಜಿಟಲ್ ಜಗತ್ತಿನಲ್ಲಿ ನಿಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಮಗ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು.