The attack surface is basically the ways the code execution can be affected/influenced by an attacker’s data/actions
1) data provided by browser (such as url, hash, cookies, local storage)
2) data received from the server (embedded on page or via AJAX calls)
3) 3rd party scripts (like the ones used for Analytics and Ads)
The impact of malicious data will depend on where/how that data is used, namely if that data ‘becomes code'.
The best places to start when mapping the attack surface of client side code is to answer these questions:
- Is the URL or Hash value provided by the Browser used in the application? If so where?
- What are all the locations where data enters the application?
- Local storage
- Ajax calls
- Is there any dynamic DOM creation?
- Is .html() used anywhere? (.text is much safer)
- Is HTML currently received from the server and dynamically inserted into the DOM?
- What 3rd party scripts are used and what are they doing?
- Where do these scripts come from?
- Do the original 3rd party scripts load more scripts dynamically?
Note that from the client-side code’s point of view, its ‘own application server' is one of the potential attackers, i.e. the client must not trust the data that is received from the server, and must ensure that all rendered data is correctly encoded in context.
Initially these mappings can be done manually, but a key objective is to calculate them using scripts (i.e. programatically), so that a baseline is kept, and security focused unit-tests can be written
Some extra additional reading on this topic