is data- attributes posing any security issues? - html

In html code, my project using data- attribute in several places like carousal, accordions, etc.
Is html data- attribute posing any security issue? Is there any better alternatives?

No, this is not a security issue, but a robust feature of modern HTML for storing and manipulating app specific data and making elements easily accessible to site scripts. Data attributes do not access or interact with databases, but serve to fill gaps where existing attributes are insufficient for the needs of your individual project, and their contents are made readily available to your site scripts via the .dataset property in the web API. They also help us to avoid storing certain kinds of information in class names, which would be inappropriate, and can be changed dynamically in the DOM.
There is language in the specification noting that the data contained in these attributes is "private" and that accessing it externally is "inappropriate" but this is not a matter of security but rather standards. They're not private in the sense that they shouldn't be accessible or that they contain sensitive information, but rather that they are specific to this application and its needed functionality, that they are subject to change by the site's scripts for it's own purposes, and they can't and shouldn't be relied upon outside of their own context.
Data attributes are primarily used to facilitate the scripts on the site by providing data for which other attributes are unsuitable. This is common in front end frameworks, where you want to be able to quickly apply complex UI interactions or layout changes by attaching options to a given element.
For example, Foundation has an option called Equalizer, which uses JavaScript to balance (or equalize) the height of parallel items within a common parent. One data attribute marks the container, another marks each item to be watched for height changes, and another optional attribute may contain options like whether the behavior changes when items are stacked.

Related

How to creat a 508 compliant org chart?

I've been researching this and haven't found much in terms of standard solutions for creating a 508-compliant, accessible org chart. We have images that represent organizational structure. It seems like the options would be to create an external file to link to that attempts to represent the relationships in the chart (although I'm not sure if there's a commonly accepted way to do this via text for a hierarchical tree), or maybe create an imagemap that doesn't actually link to anything externally but just exists for the labels. That seems much more of a hack. I also just thought of another potential representation - another html file (linked) that is basically just your standard list, which can represent a unlimited hierarchical complexity. Some labeled items are outside the general hierarchy (so groupings of various types within th hierarchy, etc.). Just wondering if anyone else had run into this, or just seen examples of how others have approached it?
Section 508 says, regarding web-based intranet and internet information and applications, which is probably what matters here: “(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).” Any solution that fulfills the requirement is 508 compliant. Note that this is a legal and formal matter; it does not imply that the content is really accessible.
So you can, for example, write a textual description of the organization (equivalent in content to the image) into the alt attribute. There is no defined upper limit on its length. Alternatively, you can use the longdesc attribute to link to a page containing an equivalent description, which may use all the expressive power of HTML, e.g. nested lists, or a table (which has accessibility requirements of course). Software support to longdesc is limited, if not anecdotal, but Section 508 explicitly mentions this possibility. Most sensibly, you can write a textual description, using HTML markup as needed, either in the page content (in which case you can use alt="") or on a separate page that you link to.
For a more specific answer, I think you need to ask a more specific question – like one with a real image representing an org chart.
I'm working toward a deadline that led me to this question more than five years after it was asked. Even now, if somebody hands me a visually presented org chart with no accessible fallback, Jukka's answer offers the best solution I can think of.
But what if we are part of the creation process (which is always the ideal), able to influence accessibility from the start? With well-structured semantic HTML, is it possible that no fallback will be needed? That's what I've gone in search of now, and here are a couple of resources that may be useful to someone in similar need. Both of these are licensed open source, which in both cases (using the MIT License) simply requires keeping the original copyright and license notice in the source code.
Here's a CSS solution proposed by Erin Sullivan.
And here's another that uses the Treeflex CSS library.
I always try to keep content separate from presentation, and CSS offers the possibility for continually customizing, refining and improving the presentation. I expect to use one of these in my current project, and I hope this research benefits others who are committed to better accessibility.

Elegant approach when generating html that depends on dynamic information

I am a junior programmer working with Ruby on Rails. I am curious what is the best/elegant approach when you have to show content that has different states.
For example: I have a form on a page that can be shown, hidden (replaced with some text), or disabled (three states) - depending on users rights and other variables.
Is it best to put the form in a partial? Make different partial for different form states? Use helpers to wrap the logic?
Also, what's the best approach when I only have to add(or not to add) a class tag to a HTML element (decision made depending on some variables).
the show/hidden/view must be based on some business rule, so you should not implement that purely in the front-end. For instance, if you actually fetch the data but hide it using a style, the data is not really hidden. So it should be implemented in the middle tier "Controller" of your application.

GWT HTML Widget XSS security

Might be a noobish question (most likely) but according to the official developer documents GWT's HTML widget is not XSS safe and one must exercise caution when embedding custom HTML/Script text.
So i guess my question is, why does this:
HTML testLabel = new HTML("dada<script type='text/javascript'>document.write('<b>Hello World</b>');</script>");
Not show a javascript popup? If somehow, GWT's HTML widget does protect from XSS attacks then in what types of situations does it not (so i can know what to expect)?
GWT documentation contains few articles about security (including dealing with XSS using SafeHtml).
Your example doesn't work because scripts defined via innerHTML doesn't get executed in Chrome/Firefox(i think there were some workaround for IE using defer attribute).
But you shouldn't rely on this browser restriction.. So it is better to use SafeHtml and always validate inputs from users.
I don't know about this widget in particular, but in general it is worth knowing that XSS vectors come in many many flavours. Only a small percentage actually use the script tag.
One very important factor is that they are location-dependent. For example, a string that is xss-safe outside any tags, may not be safe inside a tag's attribute value, or within a delimited string that is inside a javascript block.
They can also be browser-dependent, as many exploit 'bugs' in the document parsing model.
To get a sense of the variety of different vectors that can be abused to produce malicious javascript injection, please see these two cheat sheets
I also recommend you read the prevention cheat sheet at owasp

Browser HTML filters?

When writing filters for the Firefox Add-On 'Adblock Plus' you can write rules to completely remove certain HTML elements from the page, but filtering criteria is in fact limited to a handful of things, like class and id names and attribute values.
What I was hoping for is say a Firefox Add-On which would pass the HTML for a page to some arbitrary process you specify, where this process could reconstitute the HTML for the entire page in any arbitrary way and then have the browser display that. Is there a Firefox add-on that allows this or is this sort of operation commonly accomplished by some entirely different but well-known means (and perhaps not browser-specific).
Wouldn't this allow you to augment pages coming from some website to your browser with arbitrary new features, maybe from an entirely different website.
You are looking for Greasemonkey.

Adding ids to HTML tags for QA automation

I have a query In our application we have lots of HTML tags. During development many tags were not given any id because of no requirement.Now the QA team wants to automate the test cases using QTP. In most of the cases this tool doesn't recognizes because it does not find ids for most of the HTML tags.Now we are asked to add ids to all the HTML tags.
I want to know if there will be any effect adding id attribute to these tags. Even positive impact are welcome
I do not think there will be any either positive or negative effect : maybe the size of the HTML page will increase a bit, but probably not that much.
Still, are you sure you need to put "id" attributes on every HTML tag of your pages ? Wouldn't only a few of those be enough ? Like on form fields, on links, on error-messages ; and that's probably about it ?
One thing you must take care, though, is that "id", as in "identifers", must be unique ; which implies it might be good, before starting adding them, to define some kind of "id-policy", to say, for instance, that "ids for elements of that kind should be named that way".
And, for your next projects : have developpers add those when theyr're developping ;-)
(And following the policy, of course)
Now that I'm thinking about it : a positive effect might be that it'll be easier to write Javascript code interacting with your HTML document -- but that'll be true for next projects or evolutions for this one, when those id are already present in the HTML at the time developpers put the JS code in place...
Since there are no QTP related answers yet.
GUI recognition in QTP is object-oriented. In order to identify an object QTP needs a unique combination of object's properties, and checking them better to be as fast as possible - that is why HTML ID would be ideal.
Now, where it is especially critical - for objects that do not have other unique identifiers. The most typical example - html tables. Their contents is dynamic, their number on the page may vary. By adding HTML ID you allow recognition mechanism get straight to the right table.
Objects with other unique properties can be recognized well without HTML ID. For example, if you have a single "submit" link on the page QTP will successfully recognize it by inner text.
So the context-specific answer: don't start adding ids to every single tag. Ask automation guys to prepare a list of objects they have problem with. And add ids to those objects.
PS. It also depends on automation programming skills. There are descriptive programming and dynamic recognition methods. They allow retrieving the right objects even without ids provided.
As Albert said, QTP doesn't rely solely on elements' id, in fact due to the fact that many web applications generate different ids for each session, (as far as I remember) the id property isn't part of the default description for most web test objects.
QTP is pretty good at recognizing most simple web controls and if you're facing problems it may be the case that a Web Extensibility project will help you bridge the gap between the semantics of your web application and the raw HTML it is created in. If a complex control is recognized by QTP as a WebElement (which is actually the div that contains the span that drives the code) you will understandably have object recognition problems since there are many divs on the page but probably many less complex controls.
If you are talking about side-effects - NO. Adding ids won't cause any problems (apart from taking up some extra bytes of course)
If you really have the need to add ids, go ahead and add them.
http://www.w3.org/TR/html4/struct/links.html#anchors-with-id says: The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single element, their values must be identical.