Require API key to access /api/ path

[ghost]

I currently host Paperless-ng at https://<mydomain.com>/paperless and recently discovered that - despite requiring login to view the Paperless interface - anyone w/ my URL can theoretically access the previews of my documents using the Paperless API path, which doesn't require login or a key of any kind.

For example, when I preview a document in Paperless, it generates a URL like this:

https://<mydomain.com>/paperless/api/documents/10/preview/

I can then take that URL and use it to access any document (by changing the number) or even someone else's documents within their own Paperless instance (by changing the 'mydomain.com' portion). I tested this in a private browsing session where I wasn't logged in and it worked exactly as suspected.

Unless I'm missing something, this is a huge security vulnerability that I think would typically be resolved by requiring an API key in the URL to prevent others from snooping.

In the meantime, I've protected my instance w/ Authelia, but this also means I can no longer use the mobile app given it requires access to the /api path.

[mweimerskirch]

I can't reproduce this. But I think it might be related to your setup.
On my setups (prod as well as development), the preview URLs look like this:
https://<mydomain.com>/api/documents/10/preview/
and not
https://<mydomain.com>/paperless/api/documents/10/preview/

How did you make it run in the subfolder?

I suppose that due to the subfolder, the password restrictions don't apply.

[mweimerskirch]

I can't reproduce it with that either. Can you paste the exact line with the "PAPERLESS_FORCE_SCRIPT_NAME" from your configuration please?

[ghost]

Where would I find that? I don't see a config file in my mounted volumes (running via Docker, connected to Postgres database). The only place I have it specified is within my docker-compose file as follows:

PAPERLESS_FORCE_SCRIPT_NAME: /paperless

[mweimerskirch]

"/paperless" is the same path I tried with. Would you mind posting your docker-compose file (with all usernames and passwords redacted of course)?

[ghost]

Sure.

docker-compose

• PAPERLESS_BASE_URL=/paperless
• PAPERLESS_ALLOWED_HOSTS=subdomain.mydomain.com (the subdomain I host the /paperless subfolder on)

  paperless:
    image: jonaswinkler/paperless-ng
    container_name: paperless
    restart: unless-stopped
    environment:
      PAPERLESS_REDIS: ${PAPERLESS_REDIS}
      PAPERLESS_DBHOST: ${PAPERLESS_DB_HOST}
      PAPERLESS_DBPORT: ${PAPERLESS_DB_PORT}
      PAPERLESS_DBNAME: ${PAPERLESS_DB_DATABASE}
      PAPERLESS_DBUSER: ${PAPERLESS_DB_USER}
      PAPERLESS_DBPASS: ${PAPERLESS_DB_PASSWORD}
      PAPERLESS_OCR_LANGUAGE: eng
      PAPERLESS_ALLOWED_HOSTS: ${PAPERLESS_ALLOWED_HOSTS}
      PAPERLESS_FORCE_SCRIPT_NAME: ${PAPERLESS_BASE_URL}
      PAPERLESS_FILENAME_FORMAT: '{created_year}/{correspondent}/{created} {title}'
    volumes:
      - ${APPDATA}/paperless-ng:/usr/src/paperless/data
      - ${LOGS}/paperless-ng:/usr/src/paperless/data/log
      - ${MOUNT}/paperless/storage:/usr/src/paperless/media
      - ${MOUNT}/paperless/import:/usr/src/paperless/consume
      - ${MOUNT}/paperless/export:/usr/src/paperless/export
    depends_on:
      - postgres
      - redis
    networks:
      - nginx
      - postgres
      - redis

Nginx Config

    location /paperless {
	
		# Authelia
		include /config/nginx/authelia-location.conf;
	
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app paperless;
        set $upstream_port 8000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
		
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
		
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $server_name;
		
	}

[mweimerskirch]

I don't have the time to re-create that entire environment, but I don't see anything that could cause the problem like you described.
Not sure what else to look for.
Did you maybe set Nginx to cache pages? So that once you accessed them with authentication, the cached result is returned in the incognito window. To test for this, you can append a random parameter to the URL in your incognito window, like "?123" and see if you still get the preview.