Skip to Content
User GuidesDomain Management Guide

Domain Management Guide

Control which websites can use your feedback widget with domain restrictions.

Overview

Domain restrictions allow you to:

  • Prevent unauthorized use of your widget on other websites
  • Protect against spam from unknown sources
  • Control deployment across multiple domains
  • Support wildcards for subdomains

Default behavior: If no domains are configured, widget accepts feedback from any website.

Accessing Domain Settings

  1. Sign in to Miniback dashboard
  2. Navigate to your project
  3. Scroll to “Security Settings” section
  4. See “Allowed Domains” configuration

Adding Domains

Basic Domain

Add a single domain:

  1. Enter domain in the input field: example.com
  2. Click the ”+” (Add) button
  3. Domain appears in the list below
  4. Saves automatically

Examples:

example.com mywebsite.org feedback.company.io

Domain Format

Include:

  • ✅ Domain only: example.com
  • ✅ Subdomain: app.example.com
  • ✅ Wildcard: *.example.com

Don’t include:

  • ❌ Protocol: https://example.com
  • ❌ Port: example.com:3000
  • ❌ Path: example.com/page
  • ❌ Trailing slash: example.com/

Wildcard Patterns

Subdomain Wildcards

Match all subdomains of a domain:

Pattern: *.example.com

Matches:

  • app.example.com
  • staging.example.com
  • dev.example.com
  • www.example.com

Does NOT match:

  • example.com (root domain)
  • api.app.example.com (nested subdomain)

Root + Subdomains

To allow both root and subdomains:

example.com *.example.com

Now matches:

  • example.com
  • app.example.com
  • staging.example.com
  • www.example.com

Common Patterns

Single Production Site

example.com www.example.com

Use for: Simple websites with/without www

Production + Staging

example.com staging.example.com

Use for: Separate staging environment

All Subdomains

*.example.com

Use for: Multi-tenant apps, dynamic subdomains

Multiple Domains

example.com example.org example.net

Use for: Multiple top-level domains

Development + Production

localhost *.example.com example.com

Use for: Local development + all environments

Localhost & Development

Allowing Local Development

Add these for local testing:

localhost 127.0.0.1

Port handling:

  • Ports are ignored in matching
  • localhost:3000 matches localhost
  • localhost:8080 matches localhost

Development Servers

localhost *.local dev.example.com

Remove Before Production

⚠️ Important: Remove localhost before production deployment to prevent local testing submissions mixing with real data.

Removing Domains

  1. Find domain in the allowed domains list
  2. Click the “X” (Remove) button next to domain
  3. Confirm removal
  4. Domain removed immediately

Effect: Widget submissions from that domain are now blocked.

How Domain Restriction Works

Submission Flow

  1. User submits feedback via widget
  2. Widget includes origin domain in request
  3. Miniback checks allowed domains
  4. If match found: ✅ Accept feedback
  5. If no match: ❌ Reject with “Domain not allowed” error

Checking Logic

Empty list (no domains configured):

  • Accepts from any domain
  • ⚠️ Warning shown in dashboard

With domains configured:

Submitted from: app.staging.example.com Allowed domains: - *.example.com ✅ MATCH (wildcard) - example.org ❌ No match Result: ✅ Accepted

Security Best Practices

Always Configure Domains

Even if you trust your users:

  • Prevents widget hijacking
  • Stops spam submissions
  • Maintains data quality

Principle of Least Privilege

Only allow domains you control:

  • ❌ Don’t allow * (all domains)
  • ✅ Explicitly list each domain
  • ✅ Use wildcards only when necessary

Regular Audits

Review allowed domains:

  • Remove old staging/dev domains
  • Update after domain changes
  • Clean up test domains

Separate Projects for Different Domains

For unrelated websites:

  • Create separate projects
  • Configure domains independently
  • Isolate feedback by site

Testing Domain Restrictions

Step 1: Configure Domains

Add your test domain to allowed list.

Step 2: Submit Test Feedback

Visit your website and submit feedback via widget.

Step 3: Verify Acceptance

Check dashboard - feedback should appear.

Step 4: Test Rejection

  1. Remove domain from allowed list
  2. Try submitting feedback again
  3. Should see “Domain not allowed” error
  4. Feedback should NOT appear in dashboard

Debug with Browser Console

Open DevTools (F12) → Console:

// Successful submission ✅ Feedback submitted successfully // Rejected submission Error: Domain not allowed

Common Issues

Widget Not Working After Adding Domains

Problem: Forgot to add your actual domain

Solution:

  1. Check current domain in browser address bar
  2. Add exact domain to allowed list
  3. Include www if applicable

Wildcard Not Matching

Problem: *.example.com doesn’t match example.com

Solution:

# Add both: example.com *.example.com

Development vs Production

Problem: Works locally but not in production

Solution:

  • Add production domain to allowed list
  • Remove localhost before deployment
  • Test on production domain

Subdomain Issues

Problem: app.staging.example.com not matching *.example.com

Solution: Wildcards only match one subdomain level. For nested subdomains:

*.staging.example.com

Environment-Specific Configurations

Development

localhost 127.0.0.1 *.local dev.example.com

Staging

staging.example.com test.example.com uat.example.com

Production

example.com www.example.com

Best Practice: Separate Projects

Better approach:

  • Project 1 (Dev): Allow localhost, *.dev.example.com
  • Project 2 (Staging): Allow staging.example.com
  • Project 3 (Production): Allow example.com, www.example.com

Benefits:

  • Isolated feedback per environment
  • No cleanup needed
  • Better analytics

Advanced Scenarios

CDN/Proxy Domains

If using CDN (Cloudflare, etc.):

  • Add origin domain (where widget is embedded)
  • CDN domain typically doesn’t affect origin

Iframe Embedding

Domain restriction checks the parent page domain, not iframe domain.

Example:

Page: example.com Iframe: widgets.miniback.io → Checks: example.com → Add: example.com to allowed list

Mobile Apps

Domain restrictions don’t apply to:

  • Native mobile apps (iOS/Android)
  • Desktop applications (Electron)

These use API directly with API keys.

Third-Party Platforms

Webflow, Wix, etc.:

  • Find your published site domain
  • Add that domain to allowed list
  • May include platform subdomains

Troubleshooting

“Domain not allowed” error:

  1. Check browser address bar for exact domain
  2. Add to allowed domains (including www if needed)
  3. Test submission again
  4. Clear browser cache if needed

Widget works on some pages, not others:

  • Check if pages are on different subdomains
  • Add wildcard or specific subdomains

Changes not taking effect:

  1. Domain settings save automatically
  2. No cache - changes immediate
  3. Try hard refresh (Ctrl+F5)

Disabling Domain Restrictions

To allow from any domain:

  1. Remove all domains from allowed list
  2. Leave field empty
  3. ⚠️ Warning appears: “No domains configured”

Use with caution: Only for internal/trusted deployments.

What’s Next?


Need help? See Troubleshooting or contact support.

Last updated on