We Keep Coding

Not allow localstorage to be changed by user

I use localstorage to store things like highscore in this game: http://wacky2048.ga/
If you inspect element and on the top navigation bar (where you see Elements ... Performance), then click the >> button, click Application, you can see all the localstorage items, and if you double click, you can change it. You may need to make a move and refresh.
A lot of people know this trick so the highscore becomes meaningless.
Is there any way to stop this? I store integers and JSON stringified things (in case you want to suggest a encoding method).

The better solution would be store the data in the server. But if you really want to use localstorage consider storing the JSON as a jwt token and encrypt it using a private key which user doesn't have access.
Also when your app access that data in the localstorage always check for validity. If the token is invalid, what you can do is re fetch the information from the server.
Like i said before this is more of a dumb approach. Storing data in the server would be a better solution.
Edit: To hide the private key you could use environment variables like NODE_ENV (this depends on the framework you are using)

What should be the new URL content when using Javascript History API?

I am using AJAX to load content dynamically, in my page. (basically I have a search bar, and the search results are obtained using AJAX).
I want to make use of History API, since, After several searches(and also applying sorting and filter), if the user press browser back button, it takes them directly out of my site, instead of taking them to the previous search result.
There are several online resources about using history API, but I could find any information regarding the URL, that needs to be set using
window.history.pushState(dataObj, title, URL);
If we just set any URL maybe like www.mypage.com/value1, then, this would become a fake URL, which if bookmarked and used later, will not work.
So I was thinking of using the following appoach.
1)Set the URL to www.mypage.com?variable1=value1&variable2=value2 .....
Where value1 and value2 ... would be some information, which I use for AJAX.(In my case these values would be the search text and the filter and sort information)
2)On press of back button, retrieve the URL, spit it using "?" and "&" separators, and take action accordingly
3)If this URL is bookmarked also, I can handle it appropriately, since all the information is available as variables.
So, My question is, Is this a right approach, or is there any better(standard) way of handling such scenario ?

This is somewhat opinionated, but I think your approach sounds fine. So long as the user is able to press the back button and directly visit the URL to get the same results, then I think it is a perfectly fine way of doing it, and I cannot necessarily think of a better way.
In fact, from what I could grasp after looking into the Google search javascript code, it seems like they use a very similar method. They use history.pushState(...) to add search query URLs to browser history, and when they initialize the window, they check the history object as well as the URL to decide what search results to load using JS. That is not to say that Google is the go-to guru for proper web development, but if they are using a method like that, I think it is pretty safe to say that you would be fine to use it too.
I would definitely be interested if anyone has a better way, because that seems to be the best.

Can an attacker insert malicious code in html5 data attributes

So I learned earlier that using the data attribute in html5 you could insert values to be handled in a javascript file. e.g
Hey
the handling javascript file will have a line to handle that link tag which might do this
var value=$('.check').data('name');
window.location.href="http://www.example.com/'+value+'";
Now I was wondering, can a malicious coder exploit this? Do you need to sanitize the value before using it for a redirect?

It really depends.
An attacker can modify anything he wants in his browser, so it doesn't matter how much sanitization you put in the front-end, an attacker can work his way around all your javascript functions and the like to circumvent your front-end code.
I'm not saying that you shouldn't sanitize your input in the front-end because it will always help in terms of usability and experience for a legitimate user.
If the address that you're redirecting your user to uses that data attribute to do something with the server, then yes by all means sanitize it in both places: front and back end. Otherwise, you shouldn't worry, the worst case scenario is that a malicious user (or a knowledgable one) will end up in a 404 page.
** EDIT **
After reading your comment in this answer, here's my updated answer:
The dangers reside in how you're using that piece of information. Take as an example google analytics script:
Google provides with you a script that will help you track your visitors actions and behaviors through google analytics interface.
If you change any value in google's script, google analytics won't work, and there's no way you can hack google through the analytics script.
How does google achieve this? They put all their security in the backend, and they sanitize modifiable user input that will be rendered in a website, stored in a database or somehow interacts with the server.
Back to your case:
If you're going to use that data attribute to do a document.write(), an eval, do a database lookup or any sensitive operation (delete, update, retrieve data) then yes by all means: sanitize it.
How are you going to sanitize it? That's problem specific and more than likely you should ask a new question.

If the HTML is taken from user input or generated from user input, yes, you should definitely perform sanitation. However, if you're asking if data attributes are somehow vulnerable in a way other attributes aren't, the answer is no.

A user with access to the browser (e.g. via XSS) can insert anything into a data attribute. But (s)he can just redirect anywhere at anytime, so this trivial case is irrelevant.
If the value is set by a user via some other means, then the link could be set somewhere other than intended within the same domain. That might be annoying but it shouldn't be a security risk.
If you're doing something else, like including a javascript string for eval in the attribute and that comes from a user (e.g. via a database value), then you will create an XSS vulnerability. But you should never, ever, ever, trust user supplied values anyway. Nothing special about html data attributes there.

Do you need to sanitize the value before using it for a redirect?
No need to sanitize before, but you need to sanitize after.
In your example, if you are not sanitizing data - you can get a victim of classic XSS.
I.e: http://www.example.com/ + value, where value is search?q=<script>alert(1)</script>, and where search page actually outputs raw query to the browser.
p.s.: this is not specific to data-attributes. It will work the same with normal attributes.

store user input without mysql or php

I have a simple html application which displays words on a click of a next button. It fetches the words from a javascript object literal file. I want to mark some of the words as easy and some as difficult. How do I save this data from browser without using a mysql database?
can I edit the javascript object file directly from bowser?

If you want to take user input and store it permanently on your site, you'll have to employ some sort of server-side scripting. This doesn't have to be PHP, but it's probably the simplest way to do it. You can't use client-side javascript to write to a remote file directly.

If I understand correctly, you have JS object/array with words, you're modifying it and want to store it modified version permanently.
If so, then you can use "HTML5" localStorage.
This storage is per-browser. If you want to have single version shared between many users/browsers, then you will need some server-side support.

To save it on the client-side you could use cookies or local storage on supported browsers but this may not be the best approach if there are many words to keep track of.

client-side data storage and retrieval with html and javascript

I'm building what I am hoping to be a fairly simple, quick and dirty demo app.
So far, I've managed to build a bunch of components using only html and javascript. I know that eventually I'll hook-up a db, but at this point I'm just trying to show off some functionality.
In the page, a user can select a bunch of other users (like friends). Then they go to a separate html page and there is some sorting info based on the selected users.
So my first attempt was to put the selected users object into a cookie, and retrieve the cookie on the second page. Unfortunately, if the user changed their selection, the cookie wasn't getting updated, and my searches on StackOverflow seemed to say that deleting and updating cookies is unreliable.
I tried
function updateCookie(updatedUserList){
jQuery.cookie('userList',null);
jQuery.cookie('userList',updatedUserList);
}
but though it set the cookie to null, it wouldn't update it on the second value.
So I decided to put the selected users object into a form. Unfortunately, it looks like I can't retrieve the contents from the form on the client-side, only on the server-side.
Is there another way to do this? I've worked in PHP and Rails, but I'm trying to do this quickly and simply before building it out into something larger and am trying to avoid any server-side processing for now, which I have managed to do up to this point.

Since this is a demo, can you use HTML5? If so, you can use local storage: link text.
Another option is to use AJAX to load the other HTML page (replace whole body of the current document). Your storage variables would be stored in the <head>. This is a tightly coupled design, but again you're making a quick and dirty demo.

Is updatedUserList a string? If it's an array you might have to stringify it first:
jQuery.cookie('userList', JSON.stringify(updatedUserList))
(and of course parse it when you're retrieving it.)