are there other vulnerabilities that could occur from this?
In the PHP itself, outputting values to JavaScript requires a different encoding scheme than outputting to HTML. If you don't get it right, you face the same sort of cross-site-scripting issues as if you failed to use htmlspecialchars()
in your HTML-generating PHP:
var name= '<?= $name ?>';
<?php
echo "var name='$name';"
?>
Both of these will give you problems if your names contain apostrophes or backslashes. This is one of the few places where addslashes()
can actually be the right thing for once!
Also you should be aware that JavaScript files can be included by a <script> tag on another domain that would normally be denied access to your pages under the JavaScript Same Origin Policy. This opens you up to cross-site-information-leakage attacks if your script includes sensitive user-specific data:
<script src="http://www.targetsite.com/script.php" type="text/javascript"></script>
<script type="text/javascript">
alert('Ha ha, I know you are logged in to targetsite.com as user '+name);
</script>
Finally, you will have to cope with cacheing. If your data are highly dynamic you'd need to set no-cache headers on the script response so that browsers don't cache it. On the other hand for less often-changing data you'd want to handle expiry, etags and if-modified-since/not-modified headers so that the browser can cache more efficiently; you don't want to have 100,000 people all fetching the script again and again, causing load on your server, if you can help it.
Handling cacheing right can be quite a pain, with weird results when you get it wrong.
Which, taken together, is why PHP templating into JavaScript is generally unpopular. For the typical usage where the bulk of a script is static and the amount of data you have to add small, it is usually better to template that data into the HTML, either in the associated elements' attributes, or by hiding it in a comment that can be read from DOM, or by including an inline <script>.