Manage nul bytes in client requests

[captaincoordinates]

Issue created from this thread.

Discussion is required on whether titiler-pgstac should attempt to strip unsupported data (specifically nul bytes) in client requests. There are currently differences in how nul bytes are handled by nginx and gunicorn / uvicorn. nginx removes them by default but gunicorn and uvicorn do not.

If a nul byte is permitted past input validation it can result in a Postgres exception and an HTTP 500 response with a Postgres error message.

curl -I -X GET 'http://localhost:8081/collections/invalid%00id/info'

I propose that middleware should be used to strip unsupported data to avoid unintentionally exposing implementation detail to the client. I believe that only a malicious user would intentionally include nul bytes in requests to titiler-pgstac, perhaps as part of an attempt to probe the system for vulnerabilities.

[vincentsarago]

There are currently differences in how nul bytes are handled by nginx and gunicorn / uvicorn. nginx removes them by default but gunicorn and uvicorn do not.

Have you checked if either of those libs have considered raising 400 Bad Request when receiving nul byte?

Nginx response

curl -I -X GET https://stac.eoapi.dev/collections/copernicus-dem%00

HTTP/2 400 
server: awselb/2.0
date: Tue, 10 Feb 2026 00:52:31 GMT
content-type: text/html
content-length: 122

If upstream libraries do not care about nul byte I think titiler-pgstac should just raise 400 Bad Request when nul byte is passed.

I'm not quite sure how nul byte could be use as an attack to the pgstac database TBH

[captaincoordinates]

gunicorn has this open issue but I have not yet found anything for uvicorn.

HTTP 400 should be fairly simple to implement and I agree that this is a reasonable solution.

In my opinion security matters should not be a question of "do I understand how this could be compromised?" but rather "am I doing everything I reasonably can to secure this?". Any error message that unnecessarily leaks implementation detail, or could potentially be used to determine the specific version of a dependency, should be avoided where possible.

[vincentsarago]

In my opinion security matters should not be a question of "do I understand how this could be compromised?" but rather "am I doing everything I reasonably can to secure this?"

Sure but talking with my maintainer hat on I don't want to over complexity the code base of the application if the issue should be handled upstream.

Any error message that unnecessarily leaks implementation detail, or could potentially be used to determine the specific version of a dependency, should be avoided where possible.

is it the case here?

Solution ?

Do we have to check the input URL ?
Do we have to check all the query-params ?

[captaincoordinates]

is it the case here?

Yes, I think so, an API caller does not need to know that Postgres is used for data management so there is no reason to tell them. My point here is that "blue team" should always assume that "red team" knows more then they do, and therefore should not rely on whether or not they can think of a possible exploit. Honestly I would be surprised if there were any risk here, but I have been surprised before.

Ideally this would be handled upstream, but based on the age of the gunicorn issue and the apparent lack of uvicorn issues I don't expect that to happen soon.

Do we have to check the input URL ?
Do we have to check all the query-params ?

The middleware in my initial PR strips nul bytes from all path and query string parameters, I expect it should be fairly simple to instead perform a re.search and raise an exception if that value is detected.

If you are happy with this approach I will update the PR, though I am also happy for us to delay and consider input from others if you think that will be beneficial. I consider myself security-conscious but I do not call myself an expert, so I could be heading in the wrong direction on this.

[vincentsarago]

My main issue is that if we add this here, we might also add it in all our projects... which tells me this should be something handled at within the core libraries (maybe starlette).

might be worth to open an issue in Uvicorn

[captaincoordinates]

After reviewing RFC 3986 section 7.3 I am not sure that this is uvicorn's or gunicorn's responsibility. The text includes:

Note, however, that the "%00" percent-encoding (NUL) may require special handling and should be rejected if the application is not expecting to receive raw data within a component.

Based on the above it is possible that some applications accessed via uvicorn or gunicorn might need to accept raw data that can include nul bytes. Blocking nul bytes at the web server potentially risks breaking some applications. In my testing it is not uvicorn or gunicorn that errors with a nul byte in the URL, but Postgres. Because it is Postgres that fails then presumably it is the job of applications that use Postgres to block this character?

If I understand correctly, nginx blocks nul bytes due to a specific exploit risk within nginx - which may not apply to other web servers - and therefore should not be interpreted as a universal precedent.