• 0

HTML data-* security


Question

I have a question about the security of the data-* attributes in HTML.  Lets say we have some AJAX function that uses a product ID of an item.  I am trying to keep my javascript separate from my HTML.  So I would do something like this:

<a href="Product.aspx?id=7" class="select_product" data-productid="7">Product Name</a>

With jQuery, I would then do this:

$("a.select_product").click(function(e){
     e.preventDefault();

     var id = $(this).data("productid");

     //validate if ID is an integer
     if(isInt(id)){
          //call AJAX function
     }
});

So I validate the user input, but how can I validate that the specific product has that valid ID?  What is preventing somebody from using one of the many developer tools and changing data-productid to 8 or some other integer?

Link to comment
https://www.neowin.net/forum/topic/1218851-html-data-security/
Share on other sites

6 answers to this question

Recommended Posts

  • 0

Nothing is stopping them. What you could do is set the function onload and have the variable set "in memory" on the object. so that the click doesn't re-run and check the variable attribute again.

 

run this on ready.....

$("a.select_product").each(function(){
 
var id = $(this).data("productid");
 
$(this).click(function(e){     
e.preventDefault();
     
     //validate if ID is an 
integer     
if(isInt(id)){          //call 
AJAX function     }});
 
});

Would this work...?

  • 0

Nothing is preventing a user from modifying things. This is why you must always validate things as necessary server-side. Any and all client-side validation should be considered to be just a nice enhancement - it can take some of the strain off the server by catching some of the most common invalid inputs in form fields, such as mandatory forms fields being left blank, and it can also potentially enhance the usability of the page, the most obvious aspect being through cutting out unnecessary page reloading.

 

Regarding your example, where a user is clicking on a product, perhaps to purchase it, and you may be worried that they could change the ID of the product they purchase; you need to implement security checks in the server-side code to prevent them doing something they shouldn't be allowed to do. If they're only allowed to purchase products with certain ID's, check the supplied ID is on that list of allowed IDs for that user. Do not submit the price of the item they are purchasing to the server via AJAX, get it from your database, and get it based on the supplied ID of the item being purchase, don't make any assumptions if there are any to be made.

 

Be mindful to not try and take things unnecessarily too far though; if a user does have the ability to change the ID of the product they are purchasing, as long as they are allowed to purchase that item, and you retrieve the correct price for it, etc, it doesn't matter. You don't need to waste time trying to block the odd rare person from doing so.

 

With that said, you should perhaps consider implementing CSRF protection, which could significantly help bolster the security for things like this.

  • Like 1
  • 0
  On 21/06/2014 at 15:34, lunamonkey said:

Nothing is stopping them. What you could do is set the function onload and have the variable set "in memory" on the object. so that the click doesn't re-run and check the variable attribute again.

 

run this on ready.....

$("a.select_product").each(function(){
 
var id = $(this).data("productid");
 
$(this).click(function(e){     
e.preventDefault();
     
     //validate if ID is an 
integer     
if(isInt(id)){          //call 
AJAX function     }});
 
});

Would this work...?

 

Work to stop me from modifying the javascript/jQuery in the page and getting a different ID sent to the server via AJAX? No! I could always save an offline copy of the webpage to my computer, modify the code, open it in my browser and submit the form / AJAX request / whatever.

  • 0

There's no way to prevent someone from changing values clientside, you could set the id in a database server side before you sent the page and after the user clicks the href you can check that value with the server side value.

  • 0
  On 21/06/2014 at 15:35, theblazingangel said:

Nothing is preventing a user from modifying things. This is why you must always validate things as necessary server-side. Any and all client-side validation should be considered to be just a nice enhancement - it can take some of the strain off the server by catching some of the most common invalid inputs in form fields, such as mandatory forms fields being left blank, and it can also potentially enhance the usability of the page, the most obvious aspect being through cutting out unnecessary page reloading.

 

Regarding your example, where a user is clicking on a product, perhaps to purchase it, and you may be worried that they could change the ID of the product they purchase; you need to implement security checks in the server-side code to prevent them doing something they shouldn't be allowed to do. If they're only allowed to purchase products with certain ID's, check the supplied ID is on that list of allowed IDs for that user. Do not submit the price of the item they are purchasing to the server via AJAX, get it from your database, and get it based on the supplied ID of the item being purchase, don't make any assumptions if there are any to be made.

 

Be mindful to not try and take things unnecessarily too far though; if a user does have the ability to change the ID of the product they are purchasing, as long as they are allowed to purchase that item, and you retrieve the correct price for it, etc, it doesn't matter. You don't need to waste time trying to block the odd rare person from doing so.

 

With that said, you should perhaps consider implementing CSRF protection, which could significantly help bolster the security for things like this.

 

Yeah of course the AJAX function will just retrieve the price and other stats from the database.  The only thing it will send is the ID of the product, everything else will be retrieved from the server side (if it is in stock, price, ...).  I guess it really doesn't matter.  They can use developer tools to modify the href attribute too.

 

Thanks!

This topic is now closed to further replies.
  • Posts

    • Welcome to our cozy corner of the internet!
    • XnView Shell Extension 4.2.0 by Razvan Serea XnView Shell Extension is a powerful Windows Explorer add-on that enhances file management by providing quick image previews, thumbnails, and context menu tools without launching XnView. It supports over 500 image formats including RAW (CR2/NEF), WebP, HEIC, TIFF, and vector formats (PSD/SVG), allowing users to resize, convert, edit, and optimize images directly from the right-click menu. The lightweight integration streamlines workflows, enabling batch processing, metadata viewing (EXIF/IPTC), and seamless format conversion—ideal for photographers, designers, and casual users who need efficient file handling. Beyond basic previews, the extension offers advanced features like image rotation, format adjustments, and plugin support. Its intuitive interface ensures fast access to editing tools while maintaining system performance. XnView Shell Extension key features: 500+ Format Support – Opens and converts RAW, WebP, HEIC, TIFF, PSD, SVG, and more Batch Processing – Convert, resize, or rename multiple images at once Lossless JPEG Editing – Rotate, flip, and adjust without quality loss Metadata Preservation – Retains EXIF, IPTC, and XMP data during conversions Advanced Compression – Customize JPEG quality, PNG optimization, and WEBP settings Color Management – Handles ICC profiles, bit-depth (8/16/32-bit), and CMYK-to-RGB conversion PDF & GIF Support – Extract images from PDFs or create animated GIFs High-Speed Previews – Fast thumbnails and image previews in Windows Explorer Right-Click Actions – Quick access to resize, rotate, and convert without opening apps Plugin Extensibility – Add support for niche formats like DDS, HDR, or DICOM Download: XnShell 64-bit | Portable 64-bit | ~10.0 MB (Freeware) Download: XnShell 32-bit | Portable 32-bit | ~3.0 MB Links: XnView Shell Extension Home Page | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Another win for EU users? Ads in WhatsApp won't be coming this year by David Uzondu You might have heard that ads are making their way to WhatsApp after years of the company promising it would never happen. If you are in the EU (lucky you), you won't be seeing ads until 2026 at the earliest. A new report from POLITICO confirms that Meta, which owns the messaging service, has informed Ireland's privacy regulator that the new advertising model will not roll out in the European Union for quite some time, even as it appears elsewhere in the coming months. This is not some charitable act, of course. The delay gives European regulators time to scrutinize the plan, which involves using ad preferences from linked Facebook and Instagram accounts to target users. This situation follows a pattern of other "wins" for EU users, like the changes in iOS 17.4 that finally enabled sideloading. This opened the door for alternative app stores and the (temporary) return of games like Fortnite to iPhones in the region. Similarly, we are seeing Microsoft finally back off from shoving Edge down the throats of EU users, all thanks to the Digital Markets Act. This legislation has put pressure on big tech companies to operate more "fairly" within the bloc, leading to changes that users everywhere else can only dream of for now. These regulations are precisely what companies like Apple hate. Remember, Apple has issued a warning to Australia, telling the country not to follow Europe's lead on these matters because it would create massive security and privacy risks. Apple argues that its control over the ecosystem keeps users safe, so any attempt to break that open is dangerous. The Irish Data Protection Commission will be meeting with WhatsApp to discuss the matter further. According to Commissioner Des Hogan, they plan to discuss the ad model with other European data protection authorities to gather any collective concerns. Commissioner Dale Sunderland noted that discussions with the company are "still early days", and it is too soon to identify what, if any, specific "red line issues" might exist with Meta's advertising plans. For now, Europeans can continue using their ad-free messenger, while the rest of the world prepares for the inevitable.
    • Welcome to Neowin!
    • Idiots never imagine their insane actions troubling everyone.  
  • Recent Achievements

    • Week One Done
      Wayne Robinson earned a badge
      Week One Done
    • One Month Later
      Karan Khanna earned a badge
      One Month Later
    • Week One Done
      Karan Khanna earned a badge
      Week One Done
    • First Post
      MikeK13 earned a badge
      First Post
    • Week One Done
      OHI Accounting earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      688
    2. 2
      ATLien_0
      265
    3. 3
      Michael Scrip
      204
    4. 4
      +FloatingFatMan
      170
    5. 5
      Steven P.
      144
  • Tell a friend

    Love Neowin? Tell a friend!