If you discover a security vulnerability in react-consent-shield, please report it responsibly.

1. Do not open a public GitHub issue for security vulnerabilities
2. Send a private report to the maintainer via GitHub
3. Include as much detail as possible:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)

• Acknowledgment within 48 hours
• Regular updates on the progress
• Credit in the fix announcement (if desired)

This security policy covers:

• The react-consent-shield npm package
• The official documentation
• The demo application

• Third-party integrations
• User-implemented configurations
• Services that react-consent-shield integrates with (Google, Meta, etc.)

This library:

• Stores consent preferences in cookies and/or localStorage
• Does not transmit any data to external servers by default
• Uses cryptographic hashes for audit log verification (optional feature)

The consent cookie:

• Uses SameSite=Lax by default
• Can be configured for specific domains
• Does not contain sensitive user information

When using the GeoIP API for detection:

• User IP addresses are sent to a third-party service
• Consider using CDN headers instead for better privacy
• The library supports privacy-friendly alternatives

This library manages third-party scripts. When using service presets:

• Scripts are loaded from their official domains
• The library does not modify script content
• Users are responsible for reviewing scripts they enable

1. Keep updated: Always use the latest version
2. Review configuration: Audit your consent configuration regularly
3. Test thoroughly: Test consent flows in all supported browsers
4. Monitor cookies: Use the cookie scanner to detect undeclared cookies
5. Audit logs: Enable audit logging for compliance records

When implementing Content Security Policy headers, react-consent-shield requires the following directives:

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  connect-src 'self' https://ipwho.is https://api.country.is;

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src 'self' 'unsafe-inline';
  connect-src 'self' https://ipwho.is https://api.country.is https://www.google-analytics.com;
  img-src 'self' https://www.google-analytics.com;

• The library itself requires no unsafe-eval or external scripts
• connect-src for geo APIs is only needed if using automatic geo detection
• Third-party tracking scripts (Google, Meta, etc.) have their own CSP requirements
• Consider using nonce or hash for inline styles in strict environments

<ConsentProvider
  config={{
    geoDetection: {
      enabled: false,
      // Use manual region setting instead
      forceRegion: 'DE', // or determine server-side
    },
  }}
>

When loading react-consent-shield from a CDN (unpkg, jsdelivr, etc.), you can optionally enable Subresource Integrity to verify the file hasn't been tampered with.

SRI allows browsers to verify that resources fetched from CDNs haven't been modified. If the hash doesn't match, the browser refuses to load the script.

<!-- With SRI enabled - browser verifies integrity -->
<script
  src="https://unpkg.com/react-consent-shield@1.0.9/dist/index.umd.js"
  integrity="sha384-HASH_WILL_BE_GENERATED_ON_RELEASE"
  crossorigin="anonymous"
></script>

<!-- Without SRI - no integrity verification -->
<script src="https://unpkg.com/react-consent-shield@1.0.9/dist/index.umd.js"></script>

To generate your own SRI hash:

# Download the file and generate hash
curl -s https://unpkg.com/react-consent-shield@1.0.9/dist/index.umd.js | \
  openssl dgst -sha384 -binary | \
  openssl base64 -A

# Or use srihash.org

Pros of SRI:

• Protection against CDN compromise
• Protection against MITM attacks
• Compliance with strict security policies

Cons of SRI:

• Must update hash on every version change
• Breaks if CDN serves different content (rare)
• Slightly more complex setup

The decision to use SRI is yours. If your security policy requires integrity verification of external resources, enable it. If you prefer simpler deployment and trust your CDN, you can skip it.

We follow responsible disclosure:

1. Report received and acknowledged
2. Vulnerability confirmed and assessed
3. Fix developed and tested
4. New version released
5. Public disclosure after users have had time to update