XSS attacks affect the whole web, regardless of the stack you're using, you always have to be careful. Based on the redirect url you provided and the queries you execute, I'm assuming you're building an on-line address book. If a client were to fill in the form, saying his name were:
Your code would simply insert that in the database, properly escaped, of course. The escaping is what
mysqli_real_escape_string does. It doesn't sanitize, it protects the Database, not the site. I can't, for example, post something like
"bobby'; -- DROP TABLE contacts;", which is a basic example of an injection attack. But storing markup in a DB isn't wrong or dangerous as far as MySQL is concerned, so the data above can be safely inserted, and queried later on. However, when you request a list of contact names, you would get an alert, showing you your cookies. That's annoying, but not that bad. However, Check these examples to get a basic idea of how XSS attacks work, and what they can be used for.
They're used to bypass login systems, send client data to a third party or even inject/alter your page links to link to another, even more mallicious site:
var a= document.querySelectorAll('a');
All your links have now changed to link to another site. Your entire site navigation has been compromised.
The first step to prevent this is to sanitize your data:
$email = $_POST['email'];
if (!filter_var($email, FILTER_VALIDATE_EMAIL))
//don't insert, redirect back, with a GENERIC error message
die('Not all input fields contained the expected data');
Why, you might ask, not point out to the client which bit of data failed the checks? Simply because if you were to say "Please fill in valid emai", the attacker knows to not to use that input field, and fill in something like
email@example.com, and try his luck with the other fields.
Another useful thing to do is to avoid actual script tags from being send to the client when using user-supplied data:
//or if some markup is allowed:
echo strip_tags($someUserData, '<p><br>');
In case some markup is allowed, though, best go about that like wiki does: using custom markup like
[paragraph]text[/paragraph], to avoid having to parse the supplied DOM and filter-out all attributes that contain what might be JS.
Here's another site with an array of attack examples, and a how to defend against them.
Here's a list of XXS weak-spots, introduced by HTML5