కంటెంట్ సెక్యూరిటీ పాలసీ (CSP) మరియు క్రాస్-ఆరిజిన్ రిసోర్స్ షేరింగ్ (CORS) ఉపయోగించి ఫ్రంటెండ్ భద్రతను మెరుగుపరచడానికి ఒక సమగ్ర మార్గదర్శి, ఇది మీ వెబ్ అప్లికేషన్‌లను ఆధునిక ప్రమాదాల నుండి రక్షిస్తుంది.
ఫ్రంటెండ్ సెక్యూరిటీ హార్డనింగ్: కంటెంట్ సెక్యూరిటీ పాలసీ మరియు CORS
నేటి ఇంటర్‌కనెక్టడ్ డిజిటల్ ప్రపంచంలో, ఫ్రంటెండ్ భద్రత చాలా ముఖ్యం. వెబ్ అప్లికేషన్‌లు అత్యాధునిక దాడుల లక్ష్యంగా మారుతున్నాయి, అందువల్ల పటిష్టమైన భద్రతా చర్యలు తప్పనిసరి. సురక్షితమైన ఫ్రంటెండ్ ఆర్కిటెక్చర్‌లో రెండు కీలక భాగాలు కంటెంట్ సెక్యూరిటీ పాలసీ (CSP) మరియు క్రాస్-ఆరిజిన్ రిసోర్స్ షేరింగ్ (CORS). ఈ సమగ్ర గైడ్ ఈ టెక్నాలజీల గురించి లోతైన అవగాహనను అందిస్తుంది, ఆధునిక ప్రమాదాల నుండి మీ వెబ్ అప్లికేషన్‌లను బలోపేతం చేయడానికి ఆచరణాత్మక ఉదాహరణలు మరియు కార్యాచరణ అంతర్దృష్టులను అందిస్తుంది.
కంటెంట్ సెక్యూరిటీ పాలసీ (CSP) అంటే ఏమిటి?
కంటెంట్ సెక్యూరిటీ పాలసీ (CSP) అనేది ఒక అదనపు భద్రతా పొర, ఇది క్రాస్-సైట్ స్క్రిప్టింగ్ (XSS) మరియు డేటా ఇంజెక్షన్ దాడులు వంటి కొన్ని రకాల దాడులను గుర్తించడానికి మరియు నిరోధించడానికి సహాయపడుతుంది. వెబ్ సర్వర్ బ్రౌజర్‌కు Content-Security-Policy HTTP రెస్పాన్స్ హెడర్‌ను పంపడం ద్వారా CSP అమలు చేయబడుతుంది. ఈ హెడర్ బ్రౌజర్ ఏ మూలాల నుండి వనరులను లోడ్ చేయడానికి అనుమతించబడుతుందో ఒక వైట్‌లిస్ట్‌ను నిర్వచిస్తుంది. బ్రౌజర్ లోడ్ చేయగల కంటెంట్ మూలాలను పరిమితం చేయడం ద్వారా, CSP మీ వెబ్‌సైట్‌లో హానికరమైన కోడ్‌ను చొప్పించడం దాడి చేసేవారికి చాలా కష్టతరం చేస్తుంది.
CSP ఎలా పనిచేస్తుంది
CSP, ఆమోదించబడిన మూలాల నుండి మాత్రమే వనరులను (ఉదా., స్క్రిప్ట్‌లు, స్టైల్‌షీట్‌లు, చిత్రాలు, ఫాంట్‌లు) లోడ్ చేయమని బ్రౌజర్‌కు సూచించడం ద్వారా పనిచేస్తుంది. ఈ మూలాలు CSP హెడర్‌లో ఆదేశాల (directives) ద్వారా పేర్కొనబడతాయి. ఒక బ్రౌజర్ స్పష్టంగా అనుమతించబడని మూలం నుండి వనరును లోడ్ చేయడానికి ప్రయత్నిస్తే, అది అభ్యర్థనను బ్లాక్ చేసి, ఉల్లంఘనను నివేదిస్తుంది.
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'
ఉదాహరణ 2: ఒక నిర్దిష్ట డొమైన్ నుండి స్క్రిప్ట్‌లను అనుమతించడం
ఈ పాలసీ మీ స్వంత డొమైన్ మరియు ఒక విశ్వసనీయ CDN నుండి స్క్రిప్ట్‌లను అనుమతిస్తుంది:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
ఉదాహరణ 3: ఇన్‌లైన్ స్క్రిప్ట్‌లు మరియు స్టైల్స్‌ను నిలిపివేయడం
ఈ పాలసీ ఇన్‌లైన్ స్క్రిప్ట్‌లు మరియు స్టైల్స్‌ను అనుమతించదు, ఇది XSSకు వ్యతిరేకంగా ఒక బలమైన రక్షణ:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
ముఖ్యమైనది: ఇన్‌లైన్ స్క్రిప్ట్‌లను నిలిపివేయడానికి మీ HTMLను రీఫ్యాక్టర్ చేసి ఇన్‌లైన్ స్క్రిప్ట్‌లను బాహ్య ఫైల్‌లకు తరలించడం అవసరం.
ఉదాహరణ 4: ఇన్‌లైన్ స్క్రిప్ట్‌ల కోసం నాన్స్‌లను ఉపయోగించడం
మీరు ఇన్‌లైన్ స్క్రిప్ట్‌లను ఉపయోగించవలసి వస్తే, నిర్దిష్ట ఇన్‌లైన్ స్క్రిప్ట్ బ్లాక్‌లను వైట్‌లిస్ట్ చేయడానికి నాన్స్‌లను (క్రిప్టోగ్రాఫికల్‌గా యాదృచ్ఛిక, ఒకేసారి ఉపయోగించే టోకెన్‌లు) ఉపయోగించండి. ఇది 'unsafe-inline' కంటే సురక్షితమైనది. సర్వర్ ప్రతి అభ్యర్థనకు ఒక ప్రత్యేకమైన నాన్స్‌ను రూపొందించి, దానిని CSP హెడర్ మరియు <script> ట్యాగ్ రెండింటిలోనూ చేర్చాలి.
Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
<script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
గమనిక: ప్రతి అభ్యర్థనకు ఒక కొత్త నాన్స్‌ను రూపొందించడం గుర్తుంచుకోండి. నాన్స్‌లను మళ్లీ ఉపయోగించవద్దు!
ఉదాహరణ 5: ఇన్‌లైన్ స్టైల్స్ కోసం హాష్‌లను ఉపయోగించడం
నాన్స్‌ల మాదిరిగానే, హాష్‌లను నిర్దిష్ట ఇన్‌లైన్ <style> బ్లాక్‌లను వైట్‌లిస్ట్ చేయడానికి ఉపయోగించవచ్చు. స్టైల్ కంటెంట్ యొక్క SHA256, SHA384, లేదా SHA512 హాష్‌ను రూపొందించడం ద్వారా ఇది జరుగుతుంది.
Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
<style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
గమనిక: స్టైల్ కంటెంట్‌లో ఏదైనా మార్పు హాష్‌ను చెల్లనిదిగా చేస్తుంది కాబట్టి హాష్‌లు నాన్స్‌ల కంటే తక్కువ అనువైనవి.
ఉదాహరణ 6: CSP ఉల్లంఘనలను నివేదించడం
CSP ఉల్లంఘనలను పర్యవేక్షించడానికి, report-uri లేదా report-to ఆదేశాన్ని ఉపయోగించండి:
Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
మీరు Report-To హెడర్‌ను కూడా కాన్ఫిగర్ చేయాలి. Report-To హెడర్ ఒకటి లేదా అంతకంటే ఎక్కువ రిపోర్టింగ్ గ్రూప్‌లను నిర్వచిస్తుంది, ఇవి నివేదికలను ఎక్కడ మరియు ఎలా పంపాలో నిర్దేశిస్తాయి.
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
CSPని పరీక్షించడం మరియు అమలు చేయడం
CSPని అమలు చేయడానికి జాగ్రత్తగా ప్రణాళిక మరియు పరీక్ష అవసరం. కఠినమైన పాలసీతో ప్రారంభించి, అవసరమైన విధంగా క్రమంగా దాన్ని సడలించండి. వనరులను బ్లాక్ చేయకుండా మీ పాలసీని పరీక్షించడానికి Content-Security-Policy-Report-Only హెడర్‌ను ఉపయోగించండి. ఈ హెడర్ పాలసీని అమలు చేయకుండా ఉల్లంఘనలను నివేదిస్తుంది, ఉత్పత్తిలో పాలసీని అమలు చేయడానికి ముందు సమస్యలను గుర్తించి, సరిదిద్దడానికి మిమ్మల్ని అనుమతిస్తుంది.
Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
ఏవైనా ఉల్లంఘనలను గుర్తించడానికి బ్రౌజర్ ద్వారా ఉత్పత్తి చేయబడిన నివేదికలను విశ్లేషించి, దానికి అనుగుణంగా మీ పాలసీని సర్దుబాటు చేయండి. మీ పాలసీ సరిగ్గా పనిచేస్తోందని మీరు విశ్వసించిన తర్వాత, దాన్ని 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 ఈ పరిమితిని ఎంపిక చేసుకుని సడలించడానికి ఒక మార్గాన్ని అందిస్తుంది, హానికరమైన దాడుల నుండి రక్షిస్తూ చట్టబద్ధమైన క్రాస్-ఆరిజిన్ అభ్యర్థనలను అనుమతిస్తుంది.
సేమ్-ఆరిజిన్ పాలసీని అర్థం చేసుకోవడం
సేమ్-ఆరిజిన్ పాలసీ అనేది ఒక ప్రాథమిక భద్రతా యంత్రాంగం, ఇది ఒక వెబ్‌సైట్ నుండి హానికరమైన స్క్రిప్ట్ మరొక వెబ్‌సైట్‌లోని సున్నితమైన డేటాను యాక్సెస్ చేయకుండా నిరోధిస్తుంది. ఒక మూలం స్కీమ్ (ప్రోటోకాల్), హోస్ట్ (డొమైన్), మరియు పోర్ట్ ద్వారా నిర్వచించబడుతుంది. రెండు 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ను కలిగి ఉండవచ్చు.*ను ఉపయోగించడం ఏదైనా మూలం నుండి అభ్యర్థనలను అనుమతిస్తుంది, ఇది సాధారణంగా భద్రతా కారణాల వల్ల సిఫార్సు చేయబడదు. వనరు `file://` ప్రోటోకాల్ లేదా డేటా URI ఉపయోగించి తిరిగి పొందినప్పుడు వంటి "ఒపేక్ రెస్పాన్స్‌ల" కోసం మాత్రమే `null`ను ఉపయోగించడం సముచితం. - 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` డైనమిక్‌గా ఉత్పత్తి చేయబడినప్పుడు, ప్రతిస్పందన `Origin` అభ్యర్థన హెడర్ ఆధారంగా మారుతుందని కాషింగ్ మెకానిజమ్‌లకు సూచించడానికి ప్రతిస్పందనలో `Vary: Origin` హెడర్‌ను చేర్చాలి.
ఆచరణాత్మక CORS ఉదాహరణలు
CORS కాన్ఫిగరేషన్‌ల యొక్క కొన్ని ఆచరణాత్మక ఉదాహరణలను చూద్దాం:
ఉదాహరణ 1: ఒక నిర్దిష్ట మూలం నుండి అభ్యర్థనలను అనుమతించడం
ఈ కాన్ఫిగరేషన్ కేవలం https://www.example.com నుండి మాత్రమే అభ్యర్థనలను అనుమతిస్తుంది:
Access-Control-Allow-Origin: https://www.example.com
ఉదాహరణ 2: ఏదైనా మూలం నుండి అభ్యర్థనలను అనుమతించడం (సిఫార్సు చేయబడదు)
ఈ కాన్ఫిగరేషన్ ఏదైనా మూలం నుండి అభ్యర్థనలను అనుమతిస్తుంది. జాగ్రత్తగా ఉపయోగించండి ఎందుకంటే ఇది భద్రతా ప్రమాదాలను పరిచయం చేయగలదు:
Access-Control-Allow-Origin: *
ఉదాహరణ 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
ఉదాహరణ 4: క్రెడెన్షియల్స్‌ను అనుమతించడం
క్రెడెన్షియల్స్‌ను (ఉదా., కుక్కీలు) అనుమతించడానికి, మీరు Access-Control-Allow-Credentialsను trueకు సెట్ చేయాలి మరియు ఒక నిర్దిష్ట మూలాన్ని పేర్కొనాలి (క్రెడెన్షియల్స్‌ను అనుమతించినప్పుడు మీరు *ను ఉపయోగించలేరు):
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
మీరు మీ JavaScript fetch/XMLHttpRequest అభ్యర్థనలో credentials: 'include' ను కూడా సెట్ చేయాలి.
fetch('https://api.example.com/data', {
credentials: 'include'
})
CORS ప్రీఫ్లైట్ అభ్యర్థనలు
కొన్ని రకాల క్రాస్-ఆరిజిన్ అభ్యర్థనల కోసం (ఉదా., కస్టమ్ హెడర్‌లు లేదా GET, HEAD, లేదా application/x-www-form-urlencoded, multipart/form-data, లేదా text/plain యొక్క Content-Type తో POST కాకుండా ఇతర పద్ధతులతో కూడిన అభ్యర్థనలు), బ్రౌజర్ 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
ప్రీఫ్లైట్ ప్రతిస్పందన (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
Access-Control-Max-Age హెడర్ బ్రౌజర్ ప్రీఫ్లైట్ ప్రతిస్పందనను ఎంతసేపు కాష్ చేయగలదో నిర్దేశిస్తుంది, ప్రీఫ్లైట్ అభ్యర్థనల సంఖ్యను తగ్గిస్తుంది.
CORS మరియు JSONP
JSON విత్ ప్యాడింగ్ (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
మరియు మీరు మీ వెబ్‌సైట్‌ను (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;
ఈ CSP పాలసీ వెబ్‌సైట్‌ను స్క్రిప్ట్‌లను లోడ్ చేయడానికి మరియు APIకి కనెక్ట్ అవ్వడానికి అనుమతిస్తుంది, కానీ ఇతర డొమైన్‌లకు స్క్రిప్ట్‌లను లోడ్ చేయకుండా లేదా కనెక్ట్ అవ్వకుండా నిరోధిస్తుంది.
ముగింపు
కంటెంట్ సెక్యూరిటీ పాలసీ (CSP) మరియు క్రాస్-ఆరిజిన్ రిసోర్స్ షేరింగ్ (CORS) మీ ఫ్రంటెండ్ అప్లికేషన్‌ల భద్రతను పటిష్టం చేయడానికి అవసరమైన సాధనాలు. CSP మరియు CORSలను జాగ్రత్తగా కాన్ఫిగర్ చేయడం ద్వారా, మీరు XSS దాడులు, డేటా ఇంజెక్షన్ దాడులు, మరియు ఇతర భద్రతా దుర్బలత్వాల ప్రమాదాన్ని గణనీయంగా తగ్గించవచ్చు. కఠినమైన పాలసీతో ప్రారంభించడం, సమగ్రంగా పరీక్షించడం, మరియు మీ అప్లికేషన్‌లోని మార్పులకు మరియు అభివృద్ధి చెందుతున్న ముప్పుల స్వరూపానికి అనుగుణంగా మీ కాన్ఫిగరేషన్‌ను నిరంతరం పర్యవేక్షించడం మరియు మెరుగుపరచడం గుర్తుంచుకోండి. ఫ్రంటెండ్ భద్రతకు ప్రాధాన్యత ఇవ్వడం ద్వారా, మీరు మీ వినియోగదారులను రక్షించవచ్చు మరియు నేటి పెరుగుతున్న సంక్లిష్ట డిజిటల్ ప్రపంచంలో మీ వెబ్ అప్లికేషన్‌ల సమగ్రతను నిర్ధారించుకోవచ్చు.