I am currently investigating a mobile app API.
There is a feature which fills in a form in the app automatically. The user supplies a string which contains all the compressed form data. And then the app displays the filled in form for the user to enter some additional mandatory data, and submit.
It does all of that with two requests:
- A POST request to
POST /compressedformdata.php, which submits the data in the request message body. The server responds with status 200 OK.
- A GET request to
GET /filledoutform.php, which responds with the HTML page content (representation), with the pre-filled form in the response message body.
Apart from that, there is only the session information (cookie), and literally nothing else in both requests, to identify the resource.
The client and the user expect the GET request to return the exact data/representation that was created with the first request.
But I found that I can just repeat the first POST request with different data, and found that the
GET /filledoutform.php endpoint will return whatever was posted in this same session, with the POST request.
How insecure is it, to not specify the exact representation to be requested in this scenario?
It would be critical, when the second request returns the wrong html form. Since this whole functionality relies on it.
In a web API, this design would be catastrophic. Since the POST request could be inadvertently repeated with outdated data, when the user refreshes an old tab he'd left open with this page, for example. Or due to the risk of CSRF.
I am trying to figure out whether or not this design is safe in a mobile app API.
Normally, you would (for example) return a "201 Created" HTTP status code as response to the first POST request. And redirect to the new resource, e.g. using the Location header field. Or otherwise reference the new resource.
Is it bad that the API doesn't specify the resource, but instead just accepts anything that was previously created with