socket-function 0.67.0 → 0.68.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "socket-function",
3
- "version": "0.67.0",
3
+ "version": "0.68.0",
4
4
  "main": "index.js",
5
5
  "license": "MIT",
6
6
  "dependencies": {
@@ -86,7 +86,12 @@ export async function httpCallHandler(request: http.IncomingMessage, response: h
86
86
  }
87
87
  return hostname;
88
88
  }
89
- allowed = rootDomain(host) === rootDomain(origin);
89
+ let hostDomain = rootDomain(host);
90
+ let originDomain = rootDomain(origin);
91
+ allowed = hostDomain === originDomain;
92
+ if (!allowed) {
93
+ console.log(`Rejected CORS, hostDomain: ${hostDomain} !== ${originDomain}`);
94
+ }
90
95
  }
91
96
 
92
97
  // Allow if it has no origin, as that means it isn't a CORS request?
package/temp.md.ai.temp DELETED
@@ -1,41 +0,0 @@
1
- {
2
- "instructions": [
3
- {
4
- "messages": [
5
- {
6
- "role": "user",
7
- "header": "# user",
8
- "content": "How secure is comparing the Host and Origin headers, checking if they have the same root domain, and then adding \"Access-Control-Allow-Origin\"\n\n",
9
- "slot": "",
10
- "chStart": 0,
11
- "chEnd": 7
12
- }
13
- ],
14
- "params": {
15
- "model": "openrouter-deepseek/deepseek-chat",
16
- "max_tokens": 9999
17
- },
18
- "startIndex": 150,
19
- "endIndex": 150
20
- },
21
- {
22
- "messages": [
23
- {
24
- "role": "user",
25
- "header": "# user",
26
- "content": "How secure is comparing the Host and Origin headers, checking if they have the same root domain, and then adding \"Access-Control-Allow-Origin\"\n\n",
27
- "slot": "",
28
- "chStart": 0,
29
- "chEnd": 7
30
- }
31
- ],
32
- "params": {
33
- "model": "openrouter-deepseek/deepseek-r1",
34
- "max_tokens": 9999
35
- },
36
- "startIndex": 219,
37
- "endIndex": 219
38
- }
39
- ],
40
- "rawResult": "Comparing the `Host` and `Origin` headers to check if they have the same root domain and then dynamically setting the `Access-Control-Allow-Origin` header can be a reasonable approach to enforce cross-origin resource sharing (CORS) policies, but it has its nuances and potential pitfalls. Here's a detailed analysis of its security implications:\n\n### How It Works\n1. **Host Header**: Represents the domain of the server receiving the request.\n2. **Origin Header**: Represents the domain from which the request originates (e.g., in a cross-origin request).\n3. **Root Domain Comparison**: Check if the `Origin` and `Host` share the same root domain (e.g., `example.com` and `api.example.com`).\n4. **Access-Control-Allow-Origin**: If they match, set this header to the value of the `Origin` header to allow the request.\n\n### Security Considerations\n\n#### **1. Same-Origin Policy**\nThis approach ensures that only requests from the same root domain are allowed, which aligns with the same-origin policy. This can prevent unauthorized cross-origin requests.\n\n#### **2. Root Domain Matching**\nComparing the root domain ensures that subdomains of the same root domain are allowed. For example, `api.example.com` and `app.example.com` share the same root domain (`example.com`). This can be useful for microservices or APIs hosted on subdomains.\n\n#### **3. Potential Misconfigurations**\n- **Weak Root Domain Matching**: If the root domain matching logic is not strict, it could lead to vulnerabilities. For example, improperly parsing domains could allow `example.com.evil.com` to be treated as the same root domain.\n- **HTTP Header Spoofing**: If the server blindly trusts the `Origin` header, an attacker could spoof it to bypass CORS restrictions. Always validate the `Origin` header against a whitelist of allowed domains.\n\n#### **4. Security Best Practices**\n- **Whitelist Allowed Origins**: Instead of dynamically allowing any origin that matches the root domain, maintain a whitelist of trusted origins. This reduces the risk of allowing unintended domains.\n- **Validate Headers**: Ensure that the `Origin` and `Host` headers are properly validated to prevent spoofing or injection attacks.\n- **Use HTTPS**: Always enforce HTTPS to prevent man-in-the-middle attacks that could tamper with headers.\n- **Limit Scopes**: Only allow CORS for specific endpoints that require it, and restrict methods (e.g., `GET`, `POST`) and headers as needed.\n- **Avoid Wildcards**: Avoid using `Access-Control-Allow-Origin: *` unless absolutely necessary, as it allows access from any domain.\n\n#### **5. Additional Security Headers**\n- **Access-Control-Allow-Credentials**: Only set this to `true` if the request includes credentials (e.g., cookies) and you explicitly need to allow them.\n- **Vary: Origin**: Include this header to prevent caching issues with CORS responses.\n\n### Example Implementation (Pseudocode)\n```pseudocode\nif request.headers['Origin'] is not null:\n root_domain_origin = extract_root_domain(request.headers['Origin'])\n root_domain_host = extract_root_domain(request.headers['Host'])\n \n if root_domain_origin == root_domain_host:\n response.headers['Access-Control-Allow-Origin'] = request.headers['Origin']\n response.headers['Vary'] = 'Origin'\n else:\n deny_request()\nelse:\n deny_request()\n```\n\n### Conclusion\nThis approach can be secure if implemented carefully, but it's essential to follow best practices like strict domain validation, whitelisting origins, and enforcing HTTPS. Always test your CORS implementation thoroughly to ensure it doesn't introduce vulnerabilities."
41
- }