क्रॉस-ओरिजिन सुरक्षा अंमलबजावणी: जावास्क्रिप्ट कम्युनिकेशनसाठी सर्वोत्तम पद्धती

आजच्या इंटरकनेक्टेड वेबमध्ये, जावास्क्रिप्ट ॲप्लिकेशन्सना अनेकदा वेगवेगळ्या ओरिजिन (डोमेन, प्रोटोकॉल किंवा पोर्ट) मधील रिसोर्सेससोबत संवाद साधण्याची आवश्यकता असते. हा संवाद ब्राउझरच्या सेम-ओरिजिन पॉलिसीद्वारे नियंत्रित केला जातो, जी एक महत्त्वाची सुरक्षा यंत्रणा आहे. ही यंत्रणा दुर्भावनापूर्ण स्क्रिप्ट्सना डोमेनच्या सीमा ओलांडून संवेदनशील डेटामध्ये प्रवेश करण्यापासून रोखण्यासाठी डिझाइन केलेली आहे. तथापि, कायदेशीर क्रॉस-ओरिजिन कम्युनिकेशन अनेकदा आवश्यक असते. इथेच क्रॉस-ओरिजिन रिसोर्स शेअरिंग (CORS) उपयोगी पडते. हा लेख CORS, त्याची अंमलबजावणी आणि जावास्क्रिप्टमध्ये सुरक्षित क्रॉस-ओरिजिन कम्युनिकेशनसाठी सर्वोत्तम पद्धतींचा एक व्यापक आढावा देतो.

सेम-ओरिजिन पॉलिसी समजून घेणे

सेम-ओरिजिन पॉलिसी (SOP) ही वेब ब्राउझरमधील एक मूलभूत सुरक्षा संकल्पना आहे. ही पॉलिसी एका ओरिजिनवर चालणाऱ्या स्क्रिप्ट्सना दुसऱ्या ओरिजिनमधील रिसोर्सेसमध्ये प्रवेश करण्यापासून प्रतिबंधित करते. ओरिजिन हे प्रोटोकॉल (उदा. HTTP किंवा HTTPS), डोमेन नाव (उदा. example.com), आणि पोर्ट नंबर (उदा. 80 किंवा 443) यांच्या संयोगाने परिभाषित केले जाते. दोन URLs चे ओरिजिन तेव्हाच सारखे असते जेव्हा हे तिन्ही घटक तंतोतंत जुळतात.

उदाहरणार्थ:

• http://www.example.com आणि http://www.example.com/path: समान ओरिजिन
• http://www.example.com आणि https://www.example.com: भिन्न ओरिजिन (भिन्न प्रोटोकॉल)
• http://www.example.com आणि http://subdomain.example.com: भिन्न ओरिजिन (भिन्न डोमेन)
• http://www.example.com:80 आणि http://www.example.com:8080: भिन्न ओरिजिन (भिन्न पोर्ट)

SOP हे क्रॉस-साइट स्क्रिप्टिंग (XSS) हल्ल्यांविरुद्ध एक महत्त्वाचे संरक्षण आहे, जिथे वेबसाइटमध्ये इंजेक्ट केलेल्या दुर्भावनापूर्ण स्क्रिप्ट्स वापरकर्त्याचा डेटा चोरू शकतात किंवा वापरकर्त्याच्या वतीने अनधिकृत कृती करू शकतात.

क्रॉस-ओरिजिन रिसोर्स शेअरिंग (CORS) म्हणजे काय?

CORS ही एक यंत्रणा आहे जी HTTP हेडर्सचा वापर करून सर्व्हरला हे सूचित करण्याची परवानगी देते की कोणत्या ओरिजिन (डोमेन, स्कीम्स किंवा पोर्ट्स) ला त्यांच्या रिसोर्सेसमध्ये प्रवेश करण्याची परवानगी आहे. हे मूलतः विशिष्ट क्रॉस-ओरिजिन रिक्वेस्ट्ससाठी सेम-ओरिजिन पॉलिसी शिथिल करते, ज्यामुळे कायदेशीर कम्युनिकेशन शक्य होते आणि त्याच वेळी दुर्भावनापूर्ण हल्ल्यांपासून संरक्षण मिळते.

CORS नवीन HTTP हेडर्स जोडून कार्य करते जे परवानगी असलेल्या ओरिजिन आणि क्रॉस-ओरिजिन रिक्वेस्ट्ससाठी परवानगी असलेल्या पद्धती (उदा. GET, POST, PUT, DELETE) निर्दिष्ट करतात. जेव्हा ब्राउझर क्रॉस-ओरिजिन रिक्वेस्ट करतो, तेव्हा तो रिक्वेस्टसोबत एक Origin हेडर पाठवतो. सर्व्हर Access-Control-Allow-Origin हेडरसह प्रतिसाद देतो जे परवानगी असलेल्या ओरिजिन (किंवा ओरिजिन्स) निर्दिष्ट करते. जर रिक्वेस्टचे ओरिजिन Access-Control-Allow-Origin हेडरमधील मूल्याशी जुळत असेल (किंवा मूल्य * असेल), तर ब्राउझर जावास्क्रिप्ट कोडला प्रतिसादात प्रवेश करण्याची परवानगी देतो.

CORS कसे कार्य करते: एक सविस्तर स्पष्टीकरण

CORS प्रक्रियेमध्ये सामान्यतः दोन प्रकारच्या रिक्वेस्ट्सचा समावेश असतो:

1. सिम्पल रिक्वेस्ट्स (Simple Requests): या अशा रिक्वेस्ट्स आहेत ज्या विशिष्ट निकष पूर्ण करतात. जर एखादी रिक्वेस्ट या अटी पूर्ण करत असेल, तर ब्राउझर थेट रिक्वेस्ट पाठवतो.
2. प्रीफ्लाइटेड रिक्वेस्ट्स (Preflighted Requests): या अधिक गुंतागुंतीच्या रिक्वेस्ट्स आहेत ज्यासाठी ब्राउझरला प्रथम सर्व्हरला एक "प्रीफ्लाइट" OPTIONS रिक्वेस्ट पाठवावी लागते, हे निर्धारित करण्यासाठी की वास्तविक रिक्वेस्ट पाठवणे सुरक्षित आहे की नाही.

1. सिम्पल रिक्वेस्ट्स

एखादी रिक्वेस्ट "सिम्पल" मानली जाते जर ती खालील सर्व अटी पूर्ण करत असेल:

• पद्धत GET, HEAD, किंवा POST आहे.
• जर पद्धत POST असेल, तर Content-Type हेडर खालीलपैकी एक आहे:
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• कोणतेही कस्टम हेडर्स सेट केलेले नाहीत.

सिम्पल रिक्वेस्टचे उदाहरण:

GET /resource HTTP/1.1
Origin: http://www.example.com

ओरिजिनला परवानगी देणाऱ्या सर्व्हर प्रतिसादाचे उदाहरण:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Content-Type: application/json

{
  "data": "Some data"
}

जर Access-Control-Allow-Origin हेडर उपस्थित असेल आणि त्याचे मूल्य रिक्वेस्टच्या ओरिजिनशी जुळत असेल किंवा * वर सेट केले असेल, तर ब्राउझर स्क्रिप्टला प्रतिसाद डेटामध्ये प्रवेश करण्याची परवानगी देतो. अन्यथा, ब्राउझर प्रतिसादावरील प्रवेश अवरोधित करतो आणि कन्सोलमध्ये एक त्रुटी संदेश प्रदर्शित होतो.

2. प्रीफ्लाइटेड रिक्वेस्ट्स

जेव्हा एखादी रिक्वेस्ट "सिम्पल रिक्वेस्ट" चे निकष पूर्ण करत नाही, तेव्हा तिला "प्रीफ्लाइटेड" मानले जाते. हे सामान्यतः तेव्हा घडते जेव्हा रिक्वेस्ट भिन्न HTTP पद्धत (उदा. PUT, DELETE) वापरते, कस्टम हेडर्स सेट करते, किंवा परवानगी असलेल्या मूल्यांव्यतिरिक्त वेगळा Content-Type वापरते.

वास्तविक रिक्वेस्ट पाठवण्यापूर्वी, ब्राउझर प्रथम सर्व्हरला एक OPTIONS रिक्वेस्ट पाठवतो. या "प्रीफ्लाइट" रिक्वेस्टमध्ये खालील हेडर्स समाविष्ट असतात:

• Origin: रिक्वेस्ट करणाऱ्या पेजचे ओरिजिन.
• Access-Control-Request-Method: वास्तविक रिक्वेस्टमध्ये वापरली जाणारी HTTP पद्धत (उदा. PUT, DELETE).
• Access-Control-Request-Headers: वास्तविक रिक्वेस्टमध्ये पाठवल्या जाणाऱ्या कस्टम हेडर्सची स्वल्पविरामाने विभक्त केलेली सूची.

प्रीफ्लाइट रिक्वेस्टचे उदाहरण:

OPTIONS /resource HTTP/1.1
Origin: http://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header, Content-Type

सर्व्हरने OPTIONS रिक्वेस्टला खालील हेडर्ससह प्रतिसाद देणे आवश्यक आहे:

• Access-Control-Allow-Origin: रिक्वेस्ट करण्याची परवानगी असलेले ओरिजिन (किंवा कोणतेही ओरिजिन परवानगी देण्यासाठी *).
• Access-Control-Allow-Methods: क्रॉस-ओरिजिन रिक्वेस्ट्ससाठी परवानगी असलेल्या HTTP पद्धतींची स्वल्पविरामाने विभक्त केलेली सूची (उदा. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: रिक्वेस्टमध्ये पाठवण्याची परवानगी असलेल्या कस्टम हेडर्सची स्वल्पविरामाने विभक्त केलेली सूची.
• Access-Control-Max-Age: ब्राउझरद्वारे प्रीफ्लाइट प्रतिसाद किती सेकंदांसाठी कॅशे केला जाऊ शकतो.

प्रीफ्लाइट रिक्वेस्टला सर्व्हर प्रतिसादाचे उदाहरण:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Max-Age: 86400

जर प्रीफ्लाइट रिक्वेस्टला सर्व्हरचा प्रतिसाद सूचित करतो की वास्तविक रिक्वेस्टला परवानगी आहे, तर ब्राउझर वास्तविक रिक्वेस्ट पाठवेल. अन्यथा, ब्राउझर रिक्वेस्ट अवरोधित करेल आणि एक त्रुटी संदेश प्रदर्शित करेल.

सर्व्हर-साइडवर CORS लागू करणे

CORS प्रामुख्याने सर्व्हर-साइडवर प्रतिसादात योग्य HTTP हेडर्स सेट करून लागू केले जाते. विशिष्ट अंमलबजावणीचे तपशील वापरल्या जाणाऱ्या सर्व्हर-साइड तंत्रज्ञानावर अवलंबून बदलतील.

Node.js सह Express वापरून उदाहरण:

const express = require('express');
const cors = require('cors');
const app = express();

// सर्व ओरिजिनसाठी CORS सक्षम करा
app.use(cors());

// पर्यायाने, विशिष्ट ओरिजिनसाठी CORS कॉन्फिगर करा
// const corsOptions = {
//   origin: 'http://www.example.com'
// };
// app.use(cors(corsOptions));

app.get('/resource', (req, res) => {
  res.json({ message: 'This is a CORS-enabled resource' });
});

app.listen(3000, () => {
  console.log('Server listening on port 3000');
});

cors मिडलवेअर Express मध्ये CORS हेडर्स सेट करण्याची प्रक्रिया सोपी करते. तुम्ही cors() वापरून सर्व ओरिजिनसाठी CORS सक्षम करू शकता किंवा cors(corsOptions) वापरून विशिष्ट ओरिजिनसाठी ते कॉन्फिगर करू शकता.

Python सह Flask वापरून उदाहरण:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/resource")
def hello():
    return {"message": "This is a CORS-enabled resource"}

if __name__ == '__main__':
    app.run(debug=True)

flask_cors एक्सटेंशन Flask ॲप्लिकेशन्समध्ये CORS सक्षम करण्याचा एक सोपा मार्ग प्रदान करते. तुम्ही CORS() ला app पास करून सर्व ओरिजिनसाठी CORS सक्षम करू शकता. विशिष्ट ओरिजिनसाठी कॉन्फिगरेशन देखील शक्य आहे.

Java सह Spring Boot वापरून उदाहरण:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/resource")
                .allowedOrigins("http://www.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

Spring Boot मध्ये, तुम्ही WebMvcConfigurer वापरून CORS कॉन्फिगर करू शकता. हे परवानगी असलेल्या ओरिजिन, पद्धती, हेडर्स आणि इतर CORS सेटिंग्जवर सूक्ष्म-नियंत्रण करण्यास अनुमती देते.

CORS हेडर्स थेट सेट करणे (सर्वसामान्य उदाहरण)

तुम्ही कोणतेही फ्रेमवर्क वापरत नसल्यास, तुम्ही तुमच्या सर्व्हर-साइड कोडमध्ये (उदा. PHP, Ruby on Rails, इ.) थेट हेडर्स सेट करू शकता:

CORS सर्वोत्तम पद्धती

सुरक्षित आणि कार्यक्षम क्रॉस-ओरिजिन कम्युनिकेशन सुनिश्चित करण्यासाठी, या सर्वोत्तम पद्धतींचे पालन करा:

1. प्रोडक्शनमध्ये Access-Control-Allow-Origin: * वापरणे टाळा: सर्व ओरिजिनना तुमच्या रिसोर्सेसमध्ये प्रवेश करण्याची परवानगी देणे हे एक सुरक्षा धोका असू शकते. त्याऐवजी, परवानगी असलेल्या अचूक ओरिजिनचा उल्लेख करा.
2. HTTPS वापरा: प्रवासात डेटा संरक्षित करण्यासाठी रिक्वेस्ट करणाऱ्या आणि सर्व्ह करणाऱ्या दोन्ही ओरिजिनसाठी नेहमी HTTPS वापरा.
3. इनपुट प्रमाणित करा: इंजेक्शन हल्ले टाळण्यासाठी क्रॉस-ओरिजिन रिक्वेस्ट्समधून प्राप्त झालेला डेटा नेहमी प्रमाणित आणि सॅनिटाइज करा.
4. योग्य प्रमाणीकरण आणि अधिकृतता लागू करा: केवळ अधिकृत वापरकर्तेच संवेदनशील रिसोर्सेसमध्ये प्रवेश करू शकतील याची खात्री करा.
5. प्रीफ्लाइट प्रतिसाद कॅशे करा: प्रीफ्लाइट प्रतिसाद कॅशे करण्यासाठी आणि OPTIONS रिक्वेस्टची संख्या कमी करण्यासाठी Access-Control-Max-Age वापरा.
6. क्रेडेन्शियल्स वापरण्याचा विचार करा: जर तुमच्या API ला कुकीज किंवा HTTP प्रमाणीकरणासह प्रमाणीकरण आवश्यक असेल, तर तुम्हाला सर्व्हरवर Access-Control-Allow-Credentials हेडर true वर सेट करणे आणि तुमच्या जावास्क्रिप्ट कोडमध्ये credentials पर्याय 'include' वर सेट करणे आवश्यक आहे (उदा. fetch किंवा XMLHttpRequest वापरताना). हा पर्याय वापरताना अत्यंत सावधगिरी बाळगा, कारण योग्यरित्या हाताळले नाही तर ते सुरक्षा भेद्यता निर्माण करू शकते. तसेच, जेव्हा Access-Control-Allow-Credentials हे true वर सेट केले जाते, तेव्हा Access-Control-Allow-Origin हे "*" वर सेट केले जाऊ शकत नाही. तुम्हाला परवानगी असलेले ओरिजिन स्पष्टपणे निर्दिष्ट करणे आवश्यक आहे.
7. CORS कॉन्फिगरेशनचे नियमितपणे पुनरावलोकन आणि अद्यतन करा: जसे तुमचे ॲप्लिकेशन विकसित होते, तसे तुमचे CORS कॉन्फिगरेशन सुरक्षित राहील आणि तुमच्या गरजा पूर्ण करेल याची खात्री करण्यासाठी त्याचे नियमितपणे पुनरावलोकन आणि अद्यतन करा.
8. वेगवेगळ्या CORS कॉन्फिगरेशनचे परिणाम समजून घ्या: वेगवेगळ्या CORS कॉन्फिगरेशनच्या सुरक्षा परिणामांबद्दल जागरूक रहा आणि तुमच्या ॲप्लिकेशनसाठी योग्य असलेले कॉन्फिगरेशन निवडा.
9. तुमच्या CORS अंमलबजावणीची चाचणी घ्या: तुमची CORS अंमलबजावणी अपेक्षेप्रमाणे कार्य करत आहे आणि ती कोणतीही सुरक्षा भेद्यता निर्माण करत नाही याची खात्री करण्यासाठी त्याची सखोल चाचणी घ्या. नेटवर्क रिक्वेस्ट्स आणि प्रतिसादांची तपासणी करण्यासाठी ब्राउझर डेव्हलपर टूल्स वापरा, आणि CORS वर्तनाची पडताळणी करण्यासाठी स्वयंचलित चाचणी टूल्स वापरा.

उदाहरण: CORS सह Fetch API वापरणे

क्रॉस-ओरिजिन रिक्वेस्ट करण्यासाठी fetch API कसे वापरावे याचे उदाहरण येथे आहे:

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors', // ब्राउझरला सांगते की ही एक CORS रिक्वेस्ट आहे
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  return response.json();
})
.then(data => {
  console.log(data);
})
.catch(error => {
  console.error('There was a problem with the fetch operation:', error);
});

mode: 'cors' पर्याय ब्राउझरला सांगतो की ही एक CORS रिक्वेस्ट आहे. जर सर्व्हर ओरिजिनला परवानगी देत नसेल, तर ब्राउझर प्रतिसादावरील प्रवेश अवरोधित करेल आणि एक त्रुटी फेकली जाईल.

जर तुम्ही क्रेडेन्शियल्स (उदा. कुकीज) वापरत असाल, तर तुम्हाला credentials पर्याय 'include' वर सेट करणे आवश्यक आहे:

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // रिक्वेस्टमध्ये कुकीज समाविष्ट करा
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  // ...
});

CORS आणि JSONP

JSON with Padding (JSONP) हे सेम-ओरिजिन पॉलिसीला बायपास करण्याचे एक जुने तंत्र आहे. हे गतिशीलपणे <script> टॅग तयार करून कार्य करते जे वेगळ्या डोमेनवरून डेटा लोड करते. जरी JSONP काही विशिष्ट परिस्थितीत उपयुक्त ठरू शकते, तरी त्यात महत्त्वपूर्ण सुरक्षा मर्यादा आहेत आणि शक्य असल्यास ते टाळले पाहिजे. CORS हे क्रॉस-ओरिजिन कम्युनिकेशनसाठी प्राधान्यकृत समाधान आहे कारण ते एक अधिक सुरक्षित आणि लवचिक यंत्रणा प्रदान करते.

CORS आणि JSONP मधील मुख्य फरक:

• सुरक्षा: CORS हे JSONP पेक्षा अधिक सुरक्षित आहे कारण ते सर्व्हरला नियंत्रित करण्याची परवानगी देते की कोणत्या ओरिजिनला त्याच्या रिसोर्सेसमध्ये प्रवेश करण्याची परवानगी आहे. JSONP कोणतेही ओरिजिन नियंत्रण प्रदान करत नाही.
• HTTP पद्धती: CORS सर्व HTTP पद्धतींना (उदा. GET, POST, PUT, DELETE) समर्थन देते, तर JSONP केवळ GET रिक्वेस्टना समर्थन देते.
• त्रुटी हाताळणी: CORS हे JSONP पेक्षा चांगली त्रुटी हाताळणी प्रदान करते. जेव्हा CORS रिक्वेस्ट अयशस्वी होते, तेव्हा ब्राउझर तपशीलवार त्रुटी संदेश प्रदान करतो. JSONP त्रुटी हाताळणी केवळ स्क्रिप्ट यशस्वीरित्या लोड झाली की नाही हे शोधण्यापुरती मर्यादित आहे.

CORS समस्यांचे निवारण

CORS समस्या डीबग करणे निराशाजनक असू शकते. येथे काही सामान्य समस्यानिवारण टिपा आहेत:

• ब्राउझर कन्सोल तपासा: ब्राउझर कन्सोल सामान्यतः CORS समस्यांबद्दल तपशीलवार त्रुटी संदेश प्रदान करेल.
• नेटवर्क रिक्वेस्ट्स तपासा: रिक्वेस्ट आणि प्रतिसाद या दोन्हींच्या HTTP हेडर्सची तपासणी करण्यासाठी ब्राउझरच्या डेव्हलपर टूल्सचा वापर करा. Origin आणि Access-Control-Allow-Origin हेडर्स योग्यरित्या सेट केले आहेत याची पडताळणी करा.
• सर्व्हर-साइड कॉन्फिगरेशनची पडताळणी करा: तुमचे सर्व्हर-साइड CORS कॉन्फिगरेशन योग्य ओरिजिन, पद्धती आणि हेडर्सना परवानगी देत आहे याची खात्री करण्यासाठी पुन्हा तपासा.
• ब्राउझर कॅशे साफ करा: कधीकधी, कॅशे केलेले प्रीफ्लाइट प्रतिसाद CORS समस्या निर्माण करू शकतात. तुमचा ब्राउझर कॅशे साफ करण्याचा प्रयत्न करा किंवा खाजगी ब्राउझिंग विंडो वापरा.
• CORS प्रॉक्सी वापरा: काही प्रकरणांमध्ये, CORS निर्बंधांना बायपास करण्यासाठी तुम्हाला CORS प्रॉक्सी वापरण्याची आवश्यकता असू शकते. तथापि, लक्षात ठेवा की CORS प्रॉक्सी वापरल्याने सुरक्षा धोके निर्माण होऊ शकतात.
• चुकीच्या कॉन्फिगरेशनसाठी तपासा: सामान्य चुकीच्या कॉन्फिगरेशन शोधा जसे की गहाळ Access-Control-Allow-Origin हेडर, चुकीचे Access-Control-Allow-Methods किंवा Access-Control-Allow-Headers मूल्ये, किंवा रिक्वेस्टमध्ये चुकीचा Origin हेडर.

निष्कर्ष

क्रॉस-ओरिजिन रिसोर्स शेअरिंग (CORS) ही जावास्क्रिप्ट ॲप्लिकेशन्समध्ये सुरक्षित क्रॉस-ओरिजिन कम्युनिकेशन सक्षम करण्यासाठी एक आवश्यक यंत्रणा आहे. सेम-ओरिजिन पॉलिसी, CORS वर्कफ्लो आणि त्यात सामील असलेले विविध HTTP हेडर्स समजून घेऊन, डेव्हलपर त्यांच्या ॲप्लिकेशन्सना सुरक्षा भेद्यतेपासून संरक्षण देण्यासाठी आणि त्याच वेळी कायदेशीर क्रॉस-ओरिजिन रिक्वेस्टना परवानगी देण्यासाठी CORS प्रभावीपणे लागू करू शकतात. CORS कॉन्फिगरेशनसाठी सर्वोत्तम पद्धतींचे पालन करणे आणि आपल्या अंमलबजावणीचे नियमितपणे पुनरावलोकन करणे हे एक सुरक्षित आणि मजबूत वेब ॲप्लिकेशन राखण्यासाठी महत्त्वपूर्ण आहे.

हा व्यापक मार्गदर्शक CORS समजून घेण्यासाठी आणि लागू करण्यासाठी एक ठोस पाया प्रदान करतो. तुम्ही CORS योग्यरित्या आणि सुरक्षितपणे लागू करत आहात याची खात्री करण्यासाठी तुमच्या विशिष्ट सर्व्हर-साइड तंत्रज्ञानासाठी अधिकृत दस्तऐवज आणि संसाधनांचा सल्ला घ्यायला विसरू नका.

अधिक संसाधने

• MDN वेब डॉक्स: क्रॉस-ओरिजिन रिसोर्स शेअरिंग (CORS)
• W3C: क्रॉस-ओरिजिन रिसोर्स शेअरिंग (CORS)
• पोर्टस्विगर वेब सुरक्षा अकादमी: CORS