teynon

It appears you have switched to Laravel. That framework should take care of a lot of security vulnerabilities automatically for you as long as you don't circumvent their procedures. You can of course make your own security vulnerabilities with code, so you should still be mindful of that. I would argue that #5 and #6 of Master Coder's points are arguably not necessary to change. CDN's are pretty widely used and you are using some reasonably trustworthy sites. The one I might move into your domain specifically is bootstrap.min.js, although it's not a big deal either way. The point of #6 is to prevent other users from logging into their account while using that users computer. While this may be a security vulnerability, it is also a choice by the user. You should not be overriding the users preferences unless you have a very good reason to do so. If you were protecting sensitive information such as credit cards, bank account information, SSN's, etc, then maybe consider preventing that, but even in that case, this is a user preference and you are counteracting features built into a browser. That's just my 2 cents there. This link (http://stackoverflow.com/questions/2530/how-do-you-disable-browser-autocomplete-on-web-form-field-input-tag) has some useful information on stopping autocomplete. Although you'll notice that Firefox partially ignores the rules of the autocomplete="off" tag and asks the user if they want to autofill. With that, I will say you should make your own custom 500 page and put your Laravel installation into production mode / prevent error messages outputting to the user. Your 404 page could use some navigation back to the homepage as well.

You should consider using prepared statements. It's easy to tell your database is vulnerable to sql injection by trying to sign in with a username or password of something like test' OR 1 = 1;

I would mess with some of the string encodings. I've done this in C#, but not in PHP. Perhaps http://php.net/manual/en/function.utf8-encode.php.

Destramic, To further discuss this topic as requinix has stated, the reason you want to use prepared statements is that you prevent sql injection because the values being entered are not parsed. That is to say that if you had an SQL query like this: INSERT INTO myTable ({$myValue1}, 'monkeys') You have to worry about the quotes. You have to apply those functions because if you don't it's pretty easy for a user to attack your database. Now it's been about a year since I've done any PHP, but if I remember correctly, a user can send a certain character code that will turn into a quote and get around the stripslashes, etc. (I may be wrong or it may have been patched, I'm not sure.) Regardless, if you were to use a prepared statement, you don't have to worry about quotes at all. So for example: INSERT INTO myTable (?, 'monkeys') You can then call the query by passing the value. This sends the initial query to the database and then in a separate request, sends the parameters. So instead of parsing the values, it can simply insert them directly.

I've been maintaining my old site http://www.tomsfreelance.com even though it's kind of just a business card at this point. So I decided to implement some javascript stuff I had been working on for other reasons. So far it seems to I have some work to do in Firefox, but I think it's working pretty well otherwise. This is a bit of an oddball of a site and just about 99% javascript. Feedback is much appreciated!

http://www.w3schools.com/jquery/ajax_get.asp

... Again I post "http://www.whathaveyoutried.com" Since you seem to be looking for the quick fix for the error, change the line of code to this: $startCount = (!empty($click)) ? round($rating/$click) : 0;