I have a Grails app I'm working on that allows users to fill out a fairly lengthy application form. One of the requirements I've been given is to NOT require users to log in or create any sort of account. When they start filling out the app, I store their app ID in the session so it can be remembered from page to page. After one hour, the session expires. If they didn't finish the app, I send them an e-mail thanking them for considering us.

What I need to do is give users the ability to pick up where they left off so they can finish the application...again, without an account, without a username/login combination.

One way I thought to do this was to create a unique ID (like adbce-13428-etace-etc...) that is stored in the DB and maps to their application ID. I would then send them a link in the email that says "If you'd like to continue filling out your applicant, click the following link: myapp.com/continue/{their_unique_id}". When they click that, it looks up the unique ID in the database, gets their application ID, and puts the information back in the session so they can finish the application.

My question is: Is this bad form? Is it bad design? Is it bad for security? Why?

  • I don't see a problem with that, as long as you use a cryptographically-random UUID. Commented Apr 23, 2014 at 20:32
  • Yep, that is the plan. Java has a UUID class that will generate a random UUID, and I planned on using that as the unique ID. Commented Apr 23, 2014 at 20:39

3 Answers 3


You could leverage local storage, but then you also risk exposing it a multi-user or public computer, or usability fail if the user uses multiple computers.

In your email solution, you could add a special code/token/password in addition to your identifier. So you have the identifier (UUID) and then a secret. You do still have an exposure if the email is compromised, but if the UUID is compromised from logs, packet capture, etc. without the secret access cannot be granted through the designed channel. You could put the secret as another parameter in the URL, but that is slightly less secure since it will be exposed whereever the URL is logged since its in the GET


Hey, come on back to http://somesite.com?your_app=12345...... on the page enter the following code to continue XXXX

The application data and the secret should expire and be removed or unviewable from the user perspective after a period of time as well (secrets tend to become less secret over time).

  • I like this approach. A UUID + a secret string in an email should provide an appropriate level of security. Also, I agree that the UUID should expire. I was thinking that we could add something like "this link will expire in one week". Commented Apr 24, 2014 at 0:15

Whether it's bad for security depends on whether the information they're entering could be considered "sensitive".

Would it matter to the applicant if someone else could guess (however unlikely) their session id and get access to whatever data they've already entered? (Is confidentiality of the data important?)

Would it matter to the organization who is receiving the applicant data that part 1 could have been filled in by one person and part 2, or part 3, etc. could have been filled out by another person or persons? (Is integrity of the data important?)

If an attacker managed to figure out the process being used to achieve the "save and resume later" functionality and was able to harvest all of the data submitted, would it be bad for the organization's reputation? Would their reputation suffer?

If the answer to any of these questions is yes, then it might not be a good idea. As with most things in security, it's all about the data.

  • In this case, the data is definitely sensitive (SSN, etc.), and even bound by FERPA regulations. However, I don't think it will be possible for another user to guess their session ID, as the UUID library generates something like 2^122 possible values. The only way for an attacker to get the correct URL with the unique ID would be to hack our database...in which case, they would already be able to get at all of that sensitive data anyway. Commented Apr 23, 2014 at 21:32
  • There may be other ways that this information is leaked, SQL injection, some type of poorly protected log. You should look to multiple layers and other areas of course beyond just assuming it is a hard to guess value (if there is no fault in you generator) etc.
    – Eric G
    Commented Apr 23, 2014 at 22:13

I agree with monkeymagic's answer and assertion that "it's all about the data" and would definitely implement a secret token as Eric G suggested.

You mentioned in a comment that SSN information is entered at some point so one additional step you can implement is to obscure any particularly sensitive information previously entered when a user resumes their application. Perhaps upon resuming an in-progress application their SSN will only be displayed as: XXX-XX-1234

We know that obscuring SSN by showing only the last 4 digits is NOT a perfect solution but even if someone managed to figure out your UUID generation scheme and guess a bunch of valid URLs the likelihood of them wanting to disclose sensitive information like full SSNs is MUCH higher than the likelihood they will be motivated to continue some in-progress applications and complete them fraudulently.

Another concern is if this is an application for some process that will be picked up by humans for the next step who have the opportunity to perform some confirmation/verification it's a different problem than if the last step is "Enter the bank account number you would like us to deposit money into"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .