@Marcel they could still serve this in the response to the first request already. Or at least use an identifier, so that the app can have certainty, that they are requesting the correct data (idempotency).

@SteffenUllrich What you described is a 'safe' http method (safe = not changing server state). Idempotent means that it always gives the same result. If the first POST request gets resubmitted with different data inbetween, the GET request would give different results. That means it is not idempotent.

@Anders It's not idempotent, because it gives a different result, if the user sent the first POST request with different data inbetween.

@reed I disagree. "From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result." Which is not the case here. It's true that the response is not changing just as a result of the request itself. But an idempotent version of this would return an ID in the first request, and the GET request would then subsequently request the data with GET /filledoutform.php?id=[value]. Otherwise it's not idempotent.

@mentallurg How is this not in the scope of the InfoSec SE site? It's clearly about information security. The question is whether misusing a GET request in a non-idempotent way, against it's specification in a web API is a security concern.

@reed From my understanding the resource that the GET is requesting should be distinct and unambiguous. That's why we request data using parameters. E.g. GET /pre-filled-form.php?id=1234. This design is weird and I still think this is going against the definition of idempotent HTTP requests. You are (all!) mixing up 'safe' and 'idempotent'. Safe = do not change resources. Idempotent = returns always the same resource.

@reed Safe methods are supposed to also be idempotent.

@reed: To I just think that we have different definitions of "idempotent": This is not quite correct. There is a single definition of "idempotent". In mathematics and in the IT it has the same meaning. But according to the comments Martin Fürholz does not understand it and has wrong interpretation. Math: f( f( f(x) ) ) = f( f(x) ) = f(x). In the respect to GET this means: if you call GET one, or twice, or many times (sequencially, i.e. without any other calls), and the result is each time the same, then the implementation is idempotent.

@reed: ... But the OP says, that between GET calls POST was called. In such case not matter what GET returns it says nothing about idempotence.

The definition for HTTP reads: "Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request." I am aware of the mathematical meaning. I do understand that the different response is not due to the multiple GET request, I explained that multiple times already. I even never said otherwise. I'll update my question.

@MartinFürholz: Let's forget "idempotent". You say you would expect that "GET filledoutform.php" sends also some parameters in the URL. But URL is not the only way to pass parameters. They can be passed also via headers - via cookie header and via some custom header. 1) Check if this is the case. 2) Take two devices, trigger POST on one of them, then on the another device with different data, then trigger GET on the first one. What data returns GET - from the first device or from the second? If from the first, then will will confirm that GET tells the server what data needed, e.g. via Cookie.

@MartinFürholz: ... And if you see that GET returns always the most recent data sent by POST, no matter on what device was POST triggered, this would mean that GET returns globally the most recent data. This will mean a security problem. But even in such case GET will be idempotent, because GET doesn't change system state, i.e. doesn't change the data in the backend.

@Xander HTTP idempotency is NOT identical to mathematical idempotency. I have posted the exact definition of RFC 2616 in the comments already. Nevertheless, the question is not about idempotency. mentallurg you still confuse 'safe' with 'idempotent'.

@Xander I had rephrased my question long before your first comment. Are you reading a cached version of it? There is no mention about 'idempotency' anymore, because that led to people discussing a term, rather than my issue with the design of this mobile API.

@Xander what you are saying is that GET url.com/image001.jpg is NOT supposed to return image001.jpg everytime you call it, but it's perfectly fine if it sometimes returns image999.jpg's representation, or image444.jpg's representation. That's exactly what you're saying when you insist that "HTTP idempotency" does NOT mean that the identical GET request is supposed to return the same representation every time. But unfortunately that's exactly what it means. It's NOT the same as mathematical idempotency.

@MartinFürholz: Idempotency in the HTTP definition has the same meaning as in mathematics. HTTM method is a function that operates on the data in backend. If after the 2nd, 3rd etc requests the backend state is the same as after 1st request, method is idempotent.

@mentallurg no that means it's 'safe', could I please ask you to at least look at the definition before making bold and wrong statements here. I told you like the fifth time already that you are confusing safe http methods with idempotent http methods. And no, the definition is not the same as in mathematics, it says literally: "...have the property of "idempotence" in that..." with 'idempotence' in quotes.

@MartinFürholz: Pls don'tx mix it to chaos :) You started with idempotent. Then added "safe". Now removed idempotent. Read RFC and find any difference between what I said and RFC: A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

If you had looked at the definition for idempotence in mathematics, you would understand that it cannot even applied here.

@MartinFürholz: Your statement HTTP idempotency is NOT identical to mathematical idempotency is just wrong. Sure, the wording is different. But the meaning is absolutely the same.

@MartinFürholz:May be one of the reasons why you are confused about idempotency in HTTP is what is the subject? On what actually operates HTTP? Idempotency in HTTP is not about what a method returns, but about what does it change. The usual purpose of HTTP is to either to read some data in the backed or to change some data in the backend.

@MartinFürholz: Define symbolically the system state as "x", and an HTTP method as "f". Then the definition in RFC means the same as in math: f( f(x) ) = f(x).

No, that's once again the description for a 'safe' http method. Idempotent

in HTTP is about side-effects

@MartinFürholz: By the way, RFC 7231 has a bit cleaner definition of idempotency.

A http method that may not change the state of a resource is a SAFE method

@MartinFürholz: No. Because f( (fx) ) does not mean the system has not changed!

let's look at DELETE method

Safe methods are also idempotent, probably that's where your confusion is originating from

suppose duing 1st call it really deletes some data

I won't discuss this since you don't want to look at the definition

I'm out

in math it is f(x) = A

but 2nd call od DELETE finds nothing to delete and the systeme remains in teh same state

so f( (fx) ) = f(x) = A

so, DELETE is also idempotent

as well as GET, HEAD

if it is safe or not, doesn't have any meaning at all

DELETE is not safe, but is idempotent

OK, I see no sense to talk about indepotence any more.

but I asked you other question yesterday

@MartinFürholz: Have you checked if GET requests sends any headers / cookies?

@MartinFürholz: Because if parameters are not passed via URL, in the GET method they are then via headers, usually via cookie header

@MartinFürholz: And API is not just URL. If headers have some semantical value, they are also a part of the API.

@MartinFürholz: So, check the headers / cookies

Idempotence in HTTP is about side-effects. An idempotent HTTP method may not have side-effects when called multiple times. That implies that it also returns the same representation. Not changing the server state means that a HTTP method is 'safe'. Safe methods also are idempotent, as determined by by logic. But you are confusing safe HTTP methods with idempotent HTTP methods.

If you make a GET request to request resource stackexchange.com/image001.jpg you expect that the server returns the representation of image001.jpg EVERY TIME. And not a different image.

That assumption (that it always returns a specific well-defined representation) is to some extent the basis for the whole www. It's crucial!

If the HTTP request GET /image001.jpg returns /image001.jpg, and then /image003.jpg the next time, and GET /image004.jpg the next time, that would defeat the purpose of this HTTP method.

But that's exactly what you are implying!

> So, check the headers / cookies

Please read the original question again. I already stated that there is nothing else but the session ID in the requests.

@MartinFürholz, this argument about idempotent requests is crazy. I'll try to explain better why I believe you are wrong. An idempotent request is one that always has the same effect on the server when called N times, with N>0. A safe request is one that has no effect on the server, so every safe request is also idempotent (but not the other way around, not every idempotent request is also safe).

Wait, I need to finish typing! Welcome in the chat anyway

Hi. No, your statement that it always has the "same effect on the server" is wrong. For example take a DELETE request, which is ought to be idempotent. If you call it the first time, it has a different effect on the server than when you call it a second time!

(Because the first time it will - for example - delete a resource, but not the second time)

ok, a better word might have been "result on the server" then. Most resources I have read talk about "effect" though, so it you really want to be picky you are right, and a better word is probably "result". But it's not really the main problem in this argument

The problem is that you think an idempotent request should also always return the same data. That is not required or implied anywhere, as far as I know. And I can cite a few sources

One is RFC 7231, which has the definition of idempotent for HTTP 1.1 (but that also apply to HTTP 2.0 etc.). It says: "A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request"

tools.ietf.org/html/rfc7231

It clearly says "intended effect on the server"

Another source is Mozilla's docs: developer.mozilla.org/en-US/docs/Glossary/Idempotent

There is says: "the same effect while leaving the server in the same state. In other words, an idempotent method should not have any side-effects (except for keeping statistics)"

Other two interesting sources are two questions here on Stack Exchange: stackoverflow.com/questions/9234363/… and stackoverflow.com/questions/44906076/…

Now, in practice, if you call GET profile_image.jpg and first you get a cat, and then you get a dog, what does that mean? It just means that the profile image has changed. The GET request is always requesting the same resource (the current profile image), and it's idempotent (you can call it all you want, you are not going to affect the profile image or anything). If the profile image changes in the meanwhile, it's not because of the GET request

also imagine a common GET user request, where you get something like {name: "John", reputation: "1200"}, would that not be idempotent just because the reputation is obviously going to change over time? No, it's still idempotent

Finally, your GET filledoutform.php is idempotent as long as all it does is return the latest form data. Adding an ID like you said to get some specific form data, like GET filledoutform.php?id=1234 might make the process more elegant, maybe, or easier to understand and refactor, I don't know, but it won't change anything about idempotency.

As for the security, I don't see anything inherently insecure in this process. To make a POST request and change the form data, an attacker would have to be able to steal cookies, or perform a man-in-the-middle, and at that point they would probably be able to do much more things than just injecting a POST request

That's all

@MartinFürholz Perhaps this example might be helpful. Think of an online banking website. The first page you'll visit is a login page. You'll POST your credentials, and once the server has validated them, it'll put your authenticated user information in session state, and return a session cookie with your session id.

Then when you issue a GET request for the /account-home/ with that session cookie, it'll check the user in the session associated with the session id, and the response will be a page with the accounts and balances associated with that user. If you re-issue that same GET 500 more times, you'll always get the accounts and balances associated with that session/authenticated user.

That, effectively seems to be what's happening with the application that you're looking at.

Does that make it any clearer?

@MartinFürholz It does though, by sending the cookie with the session id. I predict that if you send that exactly GET request that you described over and over, (the method, the API endpoint, and the session cookie) you're going to get the same data back every time.

No it does not. The session ID does not change the fact, that the resource could have been manipulated by a different request in the same session. So that the user does not see the form he expected to see.

For example via CSRF

If the representation would be returned directly in the first POST request, then there would be no way to manipulate it, taken there are no other endpoints that have access to it.

@Xander

Also your 'response in chat' doesn't relate to what I wrote before that.

@MartinFürholz If the resource is mutable, and there is a CSRF, it could be changed at any time the CSRF is available to be taken advantage of by the attacker. Generally, the milliseconds between when the user submits some data and when the user reviews that data is going to be the least likely point an attacker would want to take advantage.

@MartinFürholz I was responding to your statement that it was "not clear" to you.

@MartinFürholz fact, your proposal could indeed make it worse. If the resource is mutable and a CSRF can be taken advantage of in that period, then the attacker would execute it, changing the data in the database, but the response for the POST would show the data that the user expects to see (the data they submitted) rather than the current data (the data the attacker submitted milliseconds later.)

@Xander "Generally, the milliseconds between when the user submits some data and when the user reviews that data is going to be the least likely" no, because the attacker would have to trigger the entire process. Which in fact the user himself does.

yes

@MartinFürholz And is there a CSRF?

That was an example for an attack that can be understood relatively easy. This is a mobile app where CSRF are extremely rare.

But not impossible, e.g. on a rooted device, when the app uses webviews.

And since I explained that there is 'literally nothing else' in the request, that means that would be prone to CSRF. At least in a web application. Right? @Xander

Rooted devices are generally always going to be outside of any threat model. An attacker who can modify an application on a rooted device is effectively the user.

@MartinFürholz 'And since I explained that there is 'literally nothing else' in the request, that means that would be prone to CSRF.' If that's true for the POST as well as the GET then yes, that's true, which wouldn't be uncommon for an API.

@MartinFürholz Ultimately, if you can demonstrate that the data that is POSTed is mutable and there's a reasonable path for an attacker to manipulate it between significant legitimate user interactions, that would something worth looking into. But from a security perspective, whether the data is returned as a POST response or a subsequent GET response, and whether the identifier is a querystring parameter or a session id are both irrelevant in general terms.

You have to be able to define the threat that is at issue. That the user sees different data than what they submitted is not a threat. If there is a specific risk associated with the user seeing different data than what was submitted, then that is the potential threat, and you have to be able to describe how the current architecture allows that threat to be turned into a vulnerability, and how your proposed change eliminates that vulnerability.