Home/ Questions/Q 8109751
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T01:31:11+00:00

While working with Database records ,displaying them on HTML and storing their ID into

  • 0

While working with Database records ,displaying them on HTML and storing their ID into a Hidden Field ,to get which one to update is not secure ,i tried something else but im not sure if that is enough Secure .

Currently im storing the ID and the md5 checksum of ID + Somekey within another Hidden field.

<input type="hidden" name="ID" value="1"/>
<input type="hidden" name="Hash" value="<?php echo md5($ID."MYKEY"); ?>"/>

And on back-end at PHP im doing the same thing and testing if their Equals.

<?php
  $ID = $_GET['ID'];
  $Checksum = $_GET['Hash'];

  if(md5($ID."MYKEY") == $Checksum)
  //Proceed Delete or update
?>

Im doing that because some one could just change the ID of a record and interact with someone else record.

The second solution was to check if that record was related to user by selecting it from Database and testing if that Exist’s to that specific user ,but using the Checksum i thought it could be an Optimization !

So is it enough secure to use that way ,using Checksums and generating Dynamic Key’s for each new Session.

Bests

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You SHOULD check for user permission on server side.
    Problem with checksum is that the user can change the checksum as well as the ID – and can try to guess what you used for generating the checksum.
    So get the current user from session, get if the user is allowed to change the record from the database and refuse if it isn’t.

    As far as the optimizations go – you should optimize ONLY if it turns out to be slow.

    Or to quote an expert on the matter:

    In DonaldKnuth’s paper “StructuredProgrammingWithGoToStatements”, he wrote: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

    • 0