Reading
Cross-Origin Resource Sharing CORS and the Same Origin Policy SOP are your friends here. Since the javascript in question is not hosted by http://127.0.0.1, it will run afoul of the SOP and default rules for CORS in browsers will prevent the javascript from reading the response. That covers your immediate question - you are protected by default.
Writing
However, that "reading" part is key. The browser will in all circumstances make the request to the server. The only thing CORS does is block the JavaScript from receiving the response. As such, CORS stops an attacker from reading data from elsewhere, but doesn't stop it from sending data elsewhere.
As a result if your application were to make important state changes due to receiving a request, you may end up with issues. Helpfully, CSRF tokens would protect you against such attacks. To be clear, JavaScript is not even required for an attacker to send a request elsewhere (h/t mti2935) - an img tag embedded on a page you visit can trigger a GET request to any server, making it especially easy for attackers to trigger undesired actions if your server takes actions as the result of a GET request.
Therefore if your application makes state changes without CSRF protection, and the attacker knows about the endpoint, you may be in trouble. For a real life example insecure and commonly used routers have been exploited like this. Consider this hypothetical URL in the web application hosted by a home router:
http://admin:[email protected]/enable_remote_admin_access
It enables remote admin access (aka adjusts config so that people can login to the admin section of the router from the internet), it has a well known URL, it requires basic authentication, and the router ships with a well known default username and password (admin:admin). As a result an attacker creates a webpage that makes a simple GET request to the above URL. The attacker won't get a response from the router (because of CORS) but the router still receives the request and if vulnerable, is now ready to accept admin connections from the internet. The malicious script then phones home with the victims IP address and another quick script checks their IP address to see if there is now an accessible router. If so, then the attacker has silently gained full control over the victim's home network simply because they visited the wrong page and were using a common, vulnerable router.
Arithmetic
Of course a custom application is much harder to take advantage of like this because it is a blind attack. Without information about what they are attacking, it's nearly impossible to have any success. As a result the practical risk level is likely low since the attack surface is so tiny. Still, here are some caveats to keep in mind:
- All bets are off in the event of a targeted attack. If the attacker knows you run some software locally that has a vulnerability, they just need you to visit the wrong link.
- CORS config is important. If your local app uses an overly permissive CORS configuration then an attacker could read the results and "browse" your application.
- Depending on how the network is configured, some basic port scanning may be possible.
- DNS rebinding (h/t EdC) may allow an attacker to circumvent the SOP and CORS. There can be obstacles to such an attack, but a determined attacker may improve their odds of success by using it.
