Security - Authentication & IP Restrictions

Protect your index with authentication and IP rules

Security

Opensolr gives you multiple layers of security to protect your data. You control who can access your index, from where, and what they can do. This page explains each security feature in plain language so you can set things up with confidence. For a broader look at how Opensolr protects your data at every level, see Solr Cloud Data Security.

Three Layers of Protection

Think of your Opensolr index as a building with three security checkpoints. Every request must pass through these layers before it reaches your data:

Incoming Request Layer 1 Authentication Username + Password required on every request to your index Always Active Layer 2 IP Rules Allow or block specific IP addresses from accessing your index Configurable Layer 3 Search Lock Require login on the public search page UI Optional Your Data Every request passes through all active security layers before reaching your data

HTTP Basic Authentication

Every Opensolr index is protected with HTTP Basic Authentication out of the box. This means every request — whether from your app, the API, or a browser — must include a valid username and password. Without credentials, the request is rejected immediately. For a complete guide on setting up and using HTTP auth, see Solr Index with HTTP Authentication.

Default Credentials

When you create an index, it comes with these default credentials:

Username opensolr
Password Your Opensolr API key

You can find your API key in your Opensolr Dashboard under Account Settings. For more details, see Default HTTP Auth Credentials.

Changing Your Credentials

You can change both the username and password to whatever you prefer. Here is how:

  1. Go to your Dashboard and select the index you want to secure
  2. Click the Security tab
  3. Enter your new username and password in the authentication section
  4. Click Save — your new credentials will be active within about 10 seconds
Avoid special characters in credentials

Stick to letters, numbers, underscores, and hyphens for your username and password. Characters like @, #, %, and & can cause issues with URL encoding in some HTTP clients and programming languages. To update credentials programmatically, use the API: Update HTTP Auth endpoint.

10-second propagation

After you change your credentials, there is a short delay (up to 10 seconds) before the new username and password take effect across all servers. During this window, both old and new credentials may work. After 10 seconds, only the new credentials will be accepted.

IP Restriction Rules

IP rules let you control which computers can talk to your index. Even if someone has your username and password, they cannot access your data unless their IP address is on the allowed list.

IP Addresses 192.168.1.10 10.0.0.55 203.0.113.99 Unknown IP ALLOWED IPs pass IP Firewall Handlers /select (search) /update (add data) /admin (manage) / (any handler) Only IPs in your allow list can reach your index handlers

How IP Rules Work

Each rule is a combination of two things:

IP An IP Address

The specific IP address you want to allow. This is the address of your server, your office network, or wherever your app runs.

A Request Handler

Which part of your index this IP can access — for example, /select for searching, /update for adding data, or / for everything.

Special Values

Value Where to Use What It Means
all IP Address field Allow any IP address (the whole internet)
/ Handler field Allow access to all handlers (search, update, admin, everything)

Example Rules

IP Address Handler What This Means
all /select Anyone in the world can search, but only search
10.0.0.55 / This specific server can do everything (search, update, admin)
all / Wide open — anyone can do anything (use with caution)
192.168.1.10 /update Only this IP can add or update documents
No rules = invisible index!

If your index has zero IP restriction rules, it is completely invisible to the outside world. No IP address can reach it at all — not even yours. Always make sure you have at least one rule that grants access. A common starting point is all + /select (allow anyone to search) plus your server IP + / (allow your server full access). You can manage IP rules programmatically: add rules, list existing rules, or remove rules via the API.

Best practice: lock down /update

Only allow your own server's IP address to access the /update handler. This prevents unauthorized users from adding, modifying, or deleting documents even if they somehow obtain your credentials.

! Know your server's IP

To find your server's public IP address, run curl ifconfig.me from your server's terminal. Use that IP in your rules.

Search Page Password

Every Opensolr index comes with a built-in public search page — a ready-to-use search interface at search.opensolr.com/your-index-name. By default, anyone with the link can search your index through this page.

If your data is private or internal, you can require a login before anyone can use the search page. When enabled, visitors see a login screen and must enter valid credentials before they can search.

Public Mode (Default) Anyone can search Toggle Password Mode Login required first

How It Works

  • Toggle the Search Page Password option in the Security tab of your dashboard
  • When enabled, visitors to your search page see a login prompt
  • They must enter valid HTTP credentials (the same username and password used for API access)
  • After logging in, they can search normally
Same credentials

The search page login uses the same username and password as your HTTP Basic Authentication settings (described above). If you change your auth credentials, the search page password changes too.

Security Best Practices

1 Use unique credentials per index

If you have multiple indexes, give each one a different password. If one password is ever compromised, only that index is affected — not all of them.

2 Restrict /update to your server only

The /update handler lets you add and delete documents. Lock it down to just your application server's IP address. Never allow all on /update unless you have a very good reason.

3 Keep credentials out of client-side code

Never put your Opensolr username and password in JavaScript that runs in a user's browser. Anyone can view browser source code. Keep credentials server-side only. If your frontend needs to query Opensolr directly from the browser, configure CORS instead — see CORS & AJAX Requests.

4 Enable two-factor authentication

Add an extra layer of protection to your Opensolr account itself by enabling 2FA. See How to Enable Two-Factor Authentication for setup instructions.

5 Test after changing security settings

After updating credentials or IP rules, immediately test that your application can still connect. A typo in an IP rule can lock you out of your own index.

Where to find security settings

All security features are in one place: open your Dashboard, select an index, and click the Security tab. Authentication, IP rules, and search page password are all managed from that single page.