Is the API Token generated in the API section in the Settings Tab the best way to guard against a CSRF attack within a Bubble app? Are there other prevention measures to take?
Also, re: this API token, the Bubble docs say it can be placed in the header or placed directly in the URL as a querystring parameter ‘api_token’. However, the docs say using it in a URL is not recommended because it’s less secure. How much less secure? Is it a really bad idea to use the token in a URL?
So i was in a similar situation and needed to make a GET to my bubble APi endpoint. Yep i dont get the doc saying add to the header or URL… really whats the point!..unless they explicitly state only from the backend. they have to remember its none techies reading this mainly
I was making mine client side (JS) …basically spent a few days looking at options the only thing i came up with was good old .php… So i wrote some .php and hosted it on a linux server…the .php is now my client side app API endpoint…so i make my call to this. then this makes the call to my bubble API endpoint with the token in header…server to server…so not visible in the console or those sniffing around…but the PHP will only accept a GET requests from specific domains i specify in the php… calls made from a URL or from another domain get a 2 fingered message. The token is stored outside of my domain root so when i get a valid GET from the right domain “mine” …i toddle off fetch it and use it…then pop it back. I thought this would slow stuff down…but its quick
Its dynamic…so i can use my bubble app to register domains in the PHP in order to server its self and also remove these. To make the whole process robust and ruffty tuffty … i will protect the php and lock this to a fixed IP…thats dedicated…im currently poorer than a church mouse without cheese so im saving up to buy that for Christmas
