Solr Security

First and foremost, Solr does not concern itself with security either at the document level or the communication level. It is strongly recommended that the application server containing Solr be firewalled such the only clients with access to Solr are your own. A default/example installation of Solr allows any client with access to it to add, update, and delete documents (and of course search/read too), including access to the Solr configuration and schema files and the administrative user interface.

Besides limiting port access to the Solr server, standard Java web security can be added by tuning the container and the Solr web application configuration itself via web.xml. For example, all /update URLs could require HTTP authentication.


Cross-Site Scripting (XSS)

Solr has no known cross-site scripting vulnerabilities.

Quick XSS tip:



snippet = snippet.encodeAsHTML()

Cross-Site Request Forgery (CSRF)






Path Based Authentication

Path based authentication configured at the servlet container level can be used to restrict access to urls (such as /admin and /update) to only clients specifying the correct credentials.

Using path based authentication to limit certain clients to path based request handlers with "appends" and "invariants" is also a nice way to expose a subset of the documents and constraining or defaulting any request parameters.


  <requestHandler name="/instock" class="solr.DisMaxRequestHandler" >
    <lst name="appends">
      <str name="fq">inStock:true</str>
    <lst name="invariants">
      <str name="facet.field">cat</str>

Any queries into /instock, such as /instock?q=ipod, will always be limited to documents with an indexed inStock field containing a value of "true", and all responses will include facet counts for the "cat" field.

/!\ NOTE: Solr provides access to request handlers through a general purpose /select?qt=request_handler_name URL. Prior to Solr1.4 (via SOLR-1233), request handlers named with a leading forward-slash like /select?qt=/request_handler_name could not be used, but had to be requested using /request_handler_name. Solr1.4 removed the forward-slash restriction and allows /select to work with any request handler name. Externally blocking access to /select is recommended in environments where only path-based access to request handlers is warranted.

When using patch based authentication, you will most likely want to configure your HTTP client code to use Preemptive Authentication. With SOLR-4470 preemptive authentication will be used by default in SolrJ clints, but it can be turned off on a per-request basis by doing the following to your SolrRequest before using it


With SOLR-4470 preemptive authentication works for POST requests - it did not before.

Common servlet container example

Add this inside <web-app ..> in WEB-INF/web.xml inside solr.war (or for Jetty to /example/etc/webdefault.xml file)

      <web-resource-name>Solr authenticated application</web-resource-name>


This is standardized for all servlet containers and will set up security with the following properties

Unfortunately it has not been standardized how to actually set up a "realm" in a servlet container, so its different from servlet container to servlet container.

Jetty realm example

Edit jetty.xml

In Jetty 6 Add / uncomment this section in /example/etc/jetty.xml

    <Set name="UserRealms">
      <Array type="">
          <New class="">

In Jetty 8 (which ships with Solr 4) you add this to /example/etc/jetty.xml

<Call name="addBean">
        <New class="">


guest: guest, core1-role

Of course you can configure other Realm/LoginService-implementations than HashUserRealm/HashLoginService

Security for inter-solr-node requests

Without SOLR-4470, in a cluster/cloud/distributed installation with several solr-nodes communicating internally, in practice you would not be able to add security constraint on most paths, because inter-solr-node communication (potentially) involves requests to most paths, and solr-nodes where not able to provide credentials in those internal solr-node-to-solr-node requests. SOLR-4470 introduces this ability. Basically there are two strategies for credentials to be used in solr-node-to-solr-node requests

Using 1) is the most correct way, because it prevent request from "the outside" to indirectly trigger successful inter-solr-node sub-requests that the user sending the "outside request" is not allowed to perform directly himself. Therefore 1) should be used whenever feasible. But there are cases where inter-solr-node requests are not a direct reaction to requests coming from "the outside" - e.g. requests around shard-synchronization. In such cases 2) will have to be used - you have no other credentials to use, and you certainly (potentially) want to be able to protect e.g. shard-synchronization paths. There are also border-cases like e.g. when a request from "the outside" triggers inter-solr-node requests to be issued asynchronously - e.g. when a request from "the outside" to the Collections API makes the Overseer send inter-solr-node request to the CoreAdmin API. In such case 1) ought to be used, but that would require to persist the credentials from the original request and reuse them when sub-request to CoreAdmin API is eventually performed. The current implementation in SOLR-4470 just uses 2) in such cases.

With SOLR-4470 only "basic http authentication" is supported, even though the code has been prepared for also supporting other kinds of authentication.

Default is not to include credentials in solr-node-to-solr-node requests. You will have to activate it. You do that by adding the following to solr.xml

        <str name="class">... fully qualified name of a class implementing - providing credentials for inter-solr-node requests of type 1) ...</str>
        <str name="class">... fully qualified name of a class implementing - providing credentials for inter-solr-node requests of type 2) ...</str>

  public static interface SubRequestFactory {
    AuthCredentials getFromOuterRequest(SolrQueryRequest outerRequest);

Out-of-the-box Solr comes with one implementation that you can just use - The credentials it provides for the sub-inter-solr-node-requests will be a copy of the credentials provided in the outer "super"-request.

  public static interface InternalRequestFactory {
    AuthCredentials getInternalAuthCredentials();

Out-of-the-box Solr comes with one implementation that you can just use - The credentials it provides for the inter-solr-node-requests will include http basic authentication with username taken from system property "internalAuthCredentialsBasicAuthUsername" and password taken from system property "internalAuthCredentialsBasicAuthPassword".

java -jar ... -DinternalAuthCredentialsBasicAuthUsername=<username> -DinternalAuthCredentialsBasicAuthPassword=<password> ... start.jar

You can write you own implementations of the interfaces and configure Solr to use them in solr.xml. Make sure the jar containing your implementations are present on Solr classpath (<str name="sharedLib">...</str> in solr.xml)

Providing credentials in requests from your own client

Basically "basic http authentication" requires you to add a header on the following form to your request

Authorization:Basic <base64 encoding of "<username>:<password>">

Fortunately misc tools help you do this


Before SOLR-4470 SolrJ only supports setting up credentials on SolrServer/HttpClient level - credentials being used for all requests issued through this SolrServer/HttpClient. Basically you need to get hold of the HttpClient used and set it up. E.g. for a CloudSolrServer instance

HttpClientUtil.setBasicAuth(cloudSolrServer.getLbServer().getHttpClient(), <username>, <password>);

With SOLR-4470 this has changed a little, because a class AuthCredentials encapsulating the abstract concept of credentials was introduced

HttpClientUtil.setAuthCredentials(cloudSolrServer.getLbServer().getHttpClient(), AuthCredentials.createBasicAuthCredentials(<username>, <password>));

With SOLR-4470 you are also able to provide credentials on request level, so that you can use different credentials in different requests issued through one and the same SolrServer/HttpClient. Just set the credentials on the SolrRequest before using it (it will override credentials on SolrServer/HttpClient level if set)

solrRequest.setAuthCredentials(AuthCredentials.createBasicAuthCredentials(<username>, <password>));

or use one of the helper-methods on SolrServer taking a AuthCredentials object as its last argument. E.g.

mySolrServer.add(docs, commitWithinMs, AuthCredentials.createBasicAuthCredentials(<username>, <password>))

With SOLR-4470 you have a final option. Namely overriding method manipulateRequest on your SolrServer. manipulateRequest will be called for every request you fire with this SolrServer and gives you a nice place to implement general credentials rules. E.g.

  CloudSolrServer mySolrServer = new CloudSolrServer(...) {
      protected void manipulateRequest( final SolrRequest request ) {
        if (request.getAuthCredentials() == null) {
          String path = request.getPath();
          AuthCredentials credentials = AuthCredentials.createBasicAuthCredentials(<my default username>, <my default password>); 
          if (path.contains("/update")) {
            credentials = AuthCredentials.createBasicAuthCredentials(<my update username>, <my update password>);

curl and base64 on linux

Believe something like this will work

BASE64_CREDENTIALS=$(echo -n "<username>:<password>" | base64)
curl -i --header "Authorization:Basic ${BASE64_CREDENTIALS}" <url>

javascript (using jquery and jquery-base64)

This shows how to base64 encode the "<username>:<password>" with jquery and jquery-base64. How to easily include the credentials in actual requests issued by jquery is TBD

        <script type="text/javascript">
            $(document).ready(function() {
                alert( $.base64.encode( "<username>:<password>" ) );
        Javascript base64 encoding test

You might want to download jquery-x.y.z.js and jquery.base64.js to be provided by your own web-application, instead of depending on them always being available from and :-)

Security in Solr on per-operation basis

Due to limitations on "url-pattern"'s in web.xml and the structure of URLs in Solr, it is hard to set up path based authentication on per-type-of-operation basis

Those facts makes it easy to set up path based authentication on per-collection/core basis. E.g. url-pattern "/core1/*" matchs all operations on core1. On the other hand, it makes it hard to set up path based authentication on operation basis. Lets say you want a url-pattern matching "updates" but across all cores/collections, you cannot just use url-pattern "/solr/*/update", "*/update" or "*update" - its not allowed in url-patterns. Different servlet containers provide different solutions to this problem.

You can also implement you own authorization-filter and let that deal with the authorization part - only let the container deal with the authentication. E.g. check out Solr code and find in test-framework project, make a copy and set things up like this in WEB-INF/web.xml

      <url-pattern>/*</url-pattern>  <!-- the container requires authentication for any url -->
      <role-name>*</role-name> <!-- the container authorizes any authenticated user to do anything -->


In practice you probably want to replace the "<role-name>*</role-name>" line with several lines on the form "<role-name>some_concrete_role</role-name>" - one for each actual role your realm will ever "talk about". This is because some servlet containers (including jetty v8) do not work properly with *.

Now set up RegExpAuthorizationFilter to do the authorization. Insert this filter AS THE FIRST filter in the WEB-INF/web.xml inside solr.war.



The RegExpAuthorizationFilter verifies authorization by matching paths against patterns - but support regular expression patterns. The patterns and corresponding "allowed roles" are provided to RegExpAuthorizationFilter using init-params. You provide an init-param for every "rule" you want to set up. Each init-param has to have a value on the from "<order>|<comma-separated-roles>|<path-regular-expression>" where

RegExpAuthorizationFilter iterates "rules" in the given order, matches the request-path against its path-regular-expression. If no match continues to next "rule", if match the next "rule" is never considered. If no "rules" match the request is allowed to proceed - it passed authorization so to speak. In case of a match the authenticated user will be matched against the roles in comma-separated-roles and only allowed access in case he is in one of the roles mentioned. In case he is not the filter will return a response with status-code 403 "Unauthorized".

RegExpAuthorizationFilter is not a supported part of Solr, so use it at your own risk

Resin example

See resin-security and auth-constraint

Here is an example showing how to force login for /update and /admin

       <system-property solr.solr.home="/path/to/solr/data" />
       <authenticator type="">
       <security-constraint url-pattern='/update/*' role-name='user'/>
       <security-constraint url-pattern='/admin/*' role-name='user'/>

Document Level Security

Manifold CF (Connector Framework)



Write Your Own RequestHandler or SearchComponent

*Stub - this is incomplete*



public class CustomDispatchFilter extends SolrDispatchFilter 
    // perhaps the whole request

    // or maybe just the user

    core.execute( handler, sreq, rsp );

public class AuthenticatingHandler extends RequestHandlerBase 
    HttpServletRequest httpreq = (HttpServletRequest)
      req.getContext().get( "HttpServletRequest" );
    if( httpreq.isUserInRole( "editor" ) ) {


Streaming Consideration


Streaming is disabled by default and is configured from solrconfig.xml

  <requestParsers enableRemoteStreaming="false" ... />

Web Server Level Security

Tomcat Remote Address Valve

You can limit access to server based on ip address by putting the following in server.xml

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="″/>

ZooKeeper security

* Protecting content: Per Steffensen/ZooKeeper protecting content

SolrSecurity (last edited 2014-02-19 13:26:20 by Per Steffensen)