Secure/HTTPOnly cookies untestable

[kevr]

First check

• I added a very descriptive title to this issue. (I think?)
• I used the GitHub search to find a similar issue and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.
• After submitting this, I commit to one of:
  • Implement a Pull Request for a confirmed bug.

What?

When testing a FastAPI application with normal cookies, everything works as intended. When setting secure=True, it breaks tests. The TestClient request context seems to lose information about cookies given to it via response, which breaks tests that depend on the cookie being resubmitted to the application.

Example

I've produced a small repository with this reproducible issue: https://github.com/kevr/fastapi-secure-cookie-bug

Route that causes the issue: https://github.com/kevr/fastapi-secure-cookie-bug/blob/secure_cookie_bug/secure_app/app.py#L13

Test that tests and fails: https://github.com/kevr/fastapi-secure-cookie-bug/blob/secure_cookie_bug/test/test_app.py#L8

$ pytest test
# test_secure_cookie fails.

# Load up uvicorn on another shell.
$ uvicorn --reload secure_app.app:app

# Use our app server over http localhost.
$ curl -v 'http://localhost:8000' # Gives `set-cookie`.
$ curl -b test_cookie=TEST -v 'http://localhost:8000' # Provides a `test_cookie` to the app.

Additional Comments

Am I approaching this the wrong way? I'm not sure if this is actually a bug or a "bug due to lack of understanding."

[frankie567]

I wouldn't say this is a bug, IMO this is completely expected: the Secure flag on a cookie means it should only be sent through HTTPS (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies). That's a security mechanism to prevent browsers sending a sensitive cookie (like an authentication token) through unsafe connection.

The TestClient is based on the requests library, the popular Python HTTP client, which makes sure to follow this convention. Actually, it seems to use the standard http.cookiejar library under the hood. You can see the relevant code here: https://github.com/python/cpython/blob/4844abdd700120120fc76c29d911bcb547700baf/Lib/http/cookiejar.py#L1127-L1131

To circumvent this, what I do in my projects is to have an environment/configuration variable to set the Secure flag: False in local and during testing; True in production.

[kevr]

I wouldn't say this is a bug, IMO this is completely expected: the Secure flag on a cookie means it should only be sent through HTTPS (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies). That's a security mechanism to prevent browsers sending a sensitive cookie (like an authentication token) through unsafe connection.

The TestClient is based on the requests library, the popular Python HTTP client, which makes sure to follow this convention. Actually, it seems to use the standard http.cookiejar library under the hood. You can see the relevant code here: https://github.com/python/cpython/blob/4844abdd700120120fc76c29d911bcb547700baf/Lib/http/cookiejar.py#L1127-L1131

To circumvent this, what I do in my projects is to have an environment/configuration variable to set the Secure flag: False in local and during testing; True in production.

I would call it a bug. As far as I know, TestClient is an object used to setup tests for your FastAPI application. A FastAPI application which serves out HTTP routes in general (which can be served by both HTTP and HTTPS). Not being able to test this case and check to see that everything behaved as expected is quite a drawback and removes the ability for us to actually test that feature does what we want from an HTTP perspective.

Features in such libraries should be testable; if not so, it's a complete uncertain part of the codebase which people must assume is okay, until it's not okay and everything falls apart. The fact that Response.set_cookie accepts those flags, to me, means they should be tested; or at the very least, testable.

[frankie567]

I think there are two things there:

1. Testing that the cookie has been set with the right properties
2. Testing that the cookie is correctly read

Testing that the cookie is passed or not following the flag is not of your concern; it's the one of the client (whether it is a browser or an HTTP client).

Testing that the cookie has been set with the right properties

You can test that the server correctly sets your cookie with the right properties by looking at its attributes in the response (response.cookies is a CookieJar).

app.py

@app.get("/set-cookie")
def set_cookie(response: Response):
  response.set_cookie("test_cookie", "foobar", secure=True, httponly=True)

test_app.py

def test_set_cookie():
  with TestClient(app=app) as test_client:
    response = test_client.get("/set-cookie")

    test_cookie = next(cookie for cookie in response.cookies if cookie.name == "test_cookie")
    assert test_cookie.secure
    assert test_cookie.has_nonstandard_attr("HttpOnly")
    assert test_cookie.value == "foobar"

Testing that the cookie is correctly read

Since you are making the request, it's your responsibility to pass the cookie value or not depending on the case you want to test.

app.py

@app.get("/read-cookie")
def read_cookie(test_cookie: str = Cookie(...)):
  return {"test_cookie": test_cookie}

test_app.py

def test_read_cookie():
  with TestClient(app=app) as test_client:
    response = test_client.get("/read-cookie", cookies={"test_cookie": "foobar"})

    assert response.json() == {"test_cookie": "foobar"}

Full example: https://replit.com/@frankie567/fastapi-testclient-secure-cookies

[kevr]

After looking through the code-base, I completely understand why this may be a no-go. The FastAPI application (or starlette) doesn't really concern itself with https-specific things at all, and the majority of the framework is hardcoded to work over websocket or http, which can then be proxied to via web servers like nginx.

Modifying all of that just to cover this case is a bit overkill, and would not really be useful to the majority of the code-base.

That being said, I'll definitely just workaround the issue by testing secure cookies specifically to ensure that the flag triggers the correct cookie values (like you have done here in your example test).

I wonder, are you guys open to any additions to documentation? I'd like to possibly specify this and why it's the case, and how to work around it somewhere, if that kind of contribution is welcome. Please let me know.