We administer a Java web application from an external supplier where we have access to the source code.

The user is able to provide an external URL which is stored in a database and later on embedded in a website generated by the web application. Only stuff members can supply URLs. The URL is properly escaped and embedded into the web page as a call to a redirect servlet together with three parameters:

  • external URL
  • timestamp of the database entry
  • hash code

The hash is calculated from the URL, the timestamp, and a server secret. The server secret is a GUID calculated at startup.

The redirect servlet recalculates the hash and throws an error if it doesn't match the embedded hash.

The disadvantage is that on each server restart the server secret changes and any hash will be invalid. The problem arises with search bots like Google or Yahoo which queues crawled URLs accross server restarts. Hence after restarting the server the error log is flooded with messages of invalid external URLs.

My questions:

  1. Is this a common pattern in web applications?
  2. What are the security benefits of the hash?
  3. Is it "safe" to calculate the hash without the server secret?
  4. Are there any security patterns which provide the same security benefit but which are not susceptible against server restarts?

Thank you

1 Answer 1


The scheme you describe is commonly used to ensure that a link is current, so if someone's changed the content, no other references to it will continue to work. Generating a new GUID upon reboot guards against someone making database changes while the server is down, ensuring old links are invalidated.

This scheme has almost nothing to do with security, and everything to do with data integrity. While related, these are not the same qualities.

So now ask yourself "Why do we need the hash? What are we trying to protect against?" If it's not ensuring your users always have absolutely correct and current data, you don't need the hash. If you think you do, and can somehow trust that your database won't be modified if the server is brought offline, then you could eliminate the server GUID so the URLs would survive reboots (this is where the minor security issue comes from, in case an attacker can bring your server down and change the data while it's offline.)

If you're seeing a lot of entries in your logs due to server reboots, maybe you need to determine why the server is rebooting so often that it's presenting an issue to your users. Or maybe it's not reboots that are the problem, and your data is changing much more frequently than you expect. Or maybe your users are letting their sessions time out, and trying to reuse stale data more often than you think. Make sure your user sessions are timing out appropriately for the rate of change of your data.

  • Thanks for your answer. Just a clarification: It seems not a matter of rebooting "often". Even if the server is running for three weeks or more we get those errors. This is because some search bots retry failed URLs a week later or so. I understand that the hash is against data corruption. However, if someone has access to the backing store why should he shutdown the server at all? If the backing strore data get corrupted when the server is running, nobody will detect it.
    – Claude
    Commented Oct 4, 2014 at 11:56
  • Log files could reveal the tampering. An offline machine can have all traces of logging removed. Commented Oct 4, 2014 at 19:14

You must log in to answer this question.

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