I will, but I’m 85% sure they already know – but they made a business decision to make one OAuth flow for all “platforms” for a consistent & simpler UX (at the expense of extra security risk, which they’ve accepted).

Edit: wait, did you mean email stripe or email the pentest company that authored the article of common oauth vulns?

https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html

I haven’t seen it. Thanks for sharing!

afaik, it doesn’t cover this use-case (where the Resource Server [Stripe] just uses the wrong flow – forcing us to expose our access keys to a third party).

But, curious, it lists 0 attacks for the OAuth Flow that Stripe should be using here = Client Credentials Flow.

Edit: ahhhhh, this paragraph is elucidating

The Authorization Code Flow is one of the most widely used OAuth flows in web applications. Unlike the Implicit Flow, which requests the Access Token directly to the Authorization Server, the Authorization Code Flow introduces an intermediary step. In this process, the User Agent first retrieves an Authorization Code, which the application then exchanges, along with the Client Credentials, for an Access Token. This additional step ensures that only the Client Application has access to the Access Token, preventing the User Agent from ever seeing it.

I confirmed that Stripe is using the Authorization Code Flow

curl https://connect.stripe.com/oauth/token \
-u sk_test_MgvkTWK1jRG3olSRx9B7Mmxo: \
-d “code”=”ac_123456789” \
-d “grant_type”=”authorization_code”

• source: https://docs.stripe.com/connect/oauth-reference#post-token-request

…but it does appear to be using the wrong OAuth Flow type. They give the token to us in the end. There’s no need to expose it to a third party.

So I guess “choosing the wrong flow type” would be a valid addition to the “attacks” section under Authorization Code Flow

No, I’m not forced to use Stripe.

I’m looking at mollie now, but I don’t really know of any better alternatives to Stripe. Got a recommendation?

Anything that requires a PayPal account is not an option.

Edit: Mollie won’t let us create an account unless we push >50.000 EUR/mo. Yeah, we’re a small business. We’re wayyy under that limit. So no Mollie :(

Thanks. It’s a good guess, but that’s not the case.

The developers confirmed that the only place the OAuth access tokens are stored is on my server. Of course, the dev’s server (which sees the [non-expiring!] access keys for >800,000 Stripe Accounts!) would be a ripe target for someone malicious. But it’s not designed to store the keys there. All subsequent connections to the Stripe API are done directly between my server and Stripe’s server (with no intermediary “platform”). The token is only exposed to the dev server when OAuth flow is first established. Then the dev server (effectively a MITM, by design) sends it down to my server for storing and future use.

PCI compliance on my server isn’t an issue because all sensitive payment information is tokenized.

The reason this is done is because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

• https://docs.stripe.com/connect/oauth-reference#redirect-uri

That’s why Stripe forces you to expose your access tokens to the developer’s servers.

I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.

Update: It looks like you’re describing their “Platform” option. In 2025, there’s 3 “authentication types” for Stripe Apps, as documented here

1. Platform
2. OAuth 2.0
3. Restricted API Keys

In this case, I’m talking about OAuth 2.0 (Stripe Connect), not “Platform”

I have been, but Stripe support hasn’t been helpful.

Update: one of the plugin authors finally explained it well:

It’s because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

• https://docs.stripe.com/connect/oauth-reference#redirect-uri

That’s why Stripe forces you to expose your access tokens to the developer’s servers.

I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.

Can you elaborate? Any idea why Stripe would choose this design?

I think Stripe generally has good security practices. But I just can’t understand this design choice. There has to be a reason…

Please read the question. I am not the developer; I can’t change to keycloak.

This is a big problem. At the time of writing:

1. Users cannot delete their images on Lemmy
2. If a user deletes their account, their images don’t get deleted
3. There is no WUI for admins to delete images on Lemmy
4. It is very difficult for admins to find & delete images on Lemmy (via the CLI)
5. The Lemmy team didn’t bother documenting how admins can delete images on Lemmy

How to purge images in Lemmy

pict-rs is a third-party simple image hosting service that runs along-side Lemmy for instances that allow users to upload media.

At the time of writing, there is no WUI for admins to find and delete images. You have to manually query the pict-rs database and execute an API call from the command-line. Worse: Lemmy has no documentation telling instance admins how to delete images 🤦

For the purposes of this example, let's assume you're trying to delete the following image

https://monero.town/pictrs/image/001665df-3b25-415f-8a59-3d836bb68dd1.webp

There are two API endpoints in pict-rs that can be used to delete an image

Method One: /image/delete/{delete_token}/{alias}

This API call is publicly-accessible, but it first requires you to obtain the image's `delete_token`

The `delete_token` is first returned by Lemmy when POSTing to the `/pictrs/image` endpoint

{
   "msg":"ok",
   "files":[
      {
         "file":"001665df-3b25-415f-8a59-3d836bb68dd1.webp",
         "delete_token":"d88b7f32-a56f-4679-bd93-4f334764d381"
      }
   ]
}

Two pieces of information are returned here:

1. file (aka the "alias") is the server filename of the uploaded image
2. delete_token is the token needed to delete the image

Of course, if you didn't capture this image's `delete_token` at upload-time, then you must fetch it from the postgres DB.

First, open a shell on your running postgres container. If you installed Lemmy with docker compose, use `docker compose ps` to get the "SERVICE" name of your postgres host, and then enter it with `docker exec`

docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
docker compose exec <docker_service_name> /bin/bash

For example:

user@host:/home/user/lemmy# docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
SERVICE    IMAGE                            NAME
lemmy      dessalines/lemmy:0.19.3          lemmy-lemmy-1
lemmy-ui   dessalines/lemmy-ui:0.19.3       lemmy-lemmy-ui-1
pictrs     docker.io/asonix/pictrs:0.5.4    lemmy-pictrs-1
postfix    docker.io/mwader/postfix-relay   lemmy-postfix-1
postgres   docker.io/postgres:15-alpine     lemmy-postgres-1
proxy      docker.io/library/nginx          lemmy-proxy-1
user@host:/home/user/lemmy# 

user@host:/home/user/lemmy# docker compose exec postgres /bin/bash
postgres:/# 

Connect to the database as the `lemmy` user

psql -U lemmy

For example

postgres:/# psql -U lemmy
psql (15.5)
Type "help" for help.

lemmy=# 

Query for the image by the "alias" (the filename)

select * from image_upload where pictrs_alias = '<image_filename>';

For example

lemmy=# select * from image_upload where pictrs_alias = '001665df-3b25-415f-8a59-3d836bb68dd1.webp';
 local_user_id | pictrs_alias | pictrs_delete_token | published 
---------------+--------------+---------------------+-----------
1149 | 001665df-3b25-415f-8a59-3d836bb68dd1.webp | d88b7f32-a56f-4679-bd93-4f334764d381 | 2024-02-07 11:10:17.158741+00
(1 row)

lemmy=# 

Now, take the `pictrs_delete_token` from the above output, and use it to delete the image.

The following command should be able to be run on any computer connected to the internet.

curl -i "https://<instance_domain>/pictrs/image/delete/<pictrs_delete_token>/<image_filename>"

For example:

user@disp9140:~$ curl -i "https://monero.town/pictrs/image/delete/d88b7f32-a56f-4679-bd93-4f334764d381/001665df-3b25-415f-8a59-3d836bb68dd1.webp"

HTTP/2 204 No Content
server: nginx
date: Fri, 09 Feb 2024 15:37:48 GMT
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
cache-control: private
referrer-policy: same-origin
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
X-Firefox-Spdy: h2
user@disp9140:~$ 

ⓘ Note: If you get an `incorrect_login` error, then try [a] logging into the instance in your web browser and then [b] pasting the "https://<instance_domain>/pictrs/image/delete/<pictrs_delete_token>/<image_filename>" URL into your web browser.

The image should be deleted.

Method Two: /internal/purge?alias={alias}

Alternatively, you could execute the deletion directly inside the pictrs container. This eliminates the need to fetch the `delete_token`.

First, open a shell on your running `pictrs` container. If you installed Lemmy with docker compose, use `docker compose ps` to get the "SERVICE" name of your postgres host, and then enter it with `docker exec`

docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
docker compose exec <docker_service_name> /bin/sh

For example:

user@host:/home/user/lemmy# docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
SERVICE    IMAGE                            NAME
lemmy      dessalines/lemmy:0.19.3          lemmy-lemmy-1
lemmy-ui   dessalines/lemmy-ui:0.19.3       lemmy-lemmy-ui-1
pictrs     docker.io/asonix/pictrs:0.5.4    lemmy-pictrs-1
postfix    docker.io/mwader/postfix-relay   lemmy-postfix-1
postgres   docker.io/postgres:15-alpine     lemmy-postgres-1
proxy      docker.io/library/nginx          lemmy-proxy-1
user@host:/home/user/lemmy# 

user@host:/home/user/lemmy# docker compose exec pictrs /bin/sh
~ $ 

Execute the following command inside the `pictrs` container.

wget --server-response --post-data "" --header "X-Api-Token: ${PICTRS__SERVER__API_KEY}" "http://127.0.0.1:8080/internal/purge?alias=<image_filename>"

For example:

~ $ wget --server-response --post-data "" --header "X-Api-Token: ${PICTRS__SERVER__API_KEY}" "http://127.0.0.1:8080/internal/purge?alias=001665df-3b25-415f-8a59-3d836bb68dd1.webp"
Connecting to 127.0.0.1:8080 (127.0.0.1:8080)
HTTP/1.1 200 OK
content-length: 67
connection: close
content-type: application/json
date: Wed, 14 Feb 2024 12:56:24 GMT

saving to 'purge?alias=001665df-3b25-415f-8a59-3d836bb68dd1.webp'
purge?alias=001665df 100% |*****************************************************************************************************************************************************************************************************************************| 67 0:00:00 ETA
'purge?alias=001665df-3b25-415f-8a59-3d836bb68dd1.webp' saved

~ $ 

ⓘ Note: There's an error in the pict-rs reference documentation. It says you can POST to `/internal/delete`, but that just returns 404 Not Found.

The image should be deleted

Further Reading

Unfortunately, it seems that the Lemmy develoeprs are not taking these moral and legal (GDPR) risks seriously (they said it may take years before they address them), and they threatened to ban me for trying to highlight the severity of this risk, get them to tag GDPR-related bugs, and to prioritize them.

• lemmy #4433: Deleted Account should delete uploaded media (pictures) too
• lemmy #4441: Users unable to delete their images (pictrs API)
• lemmy #4434: Unapproved users cannot delete their accounts/data
• lemmy #3973: Banned users cannot delete their accounts/data
• lemmy #4445: Create an interface for local users to view and remove images
• lemmy-ui #2359: Allow users to delete images they uploaded
• lemmy-ui #2360: Allow admins to view & delete uploaded images
• lemmy-ui #2361: private_message_disclaimer to include user's matrix handle
• jerboa #1361: UI for deleting uploaded files
• jerboa #1362: Setting to hide "upload media" button
• jerboa #1363: Add "confirm upload" step to UX
• lemmy-docs #293: Document image moderation

If GDPR-compliance is important to you on the fediverse, then please provide feedback to the Lemmy developers in the GitHub links above.

Attribution

This comment was copied from the following article: Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)

Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)

• https://tech.michaelaltfield.net/2024/03/04/lemmy-fediverse-gdpr/