Cross-Site Scripting: Bookmark Managers Have Critical Security Boundaries to Uphold
Imagine you are working from home and need to get into something on your company's network. You open the same VPN page you have used before, sign in like you always do, and go about your business. The website address belongs to your company and the page is part of the system your employer told you to use. There is no obvious reason to think twice about what's going on in the background.
One product commonly used by businesses for VPN access is GlobalProtect, made by Palo Alto Networks, to let people access their private networks from anywhere. Many people know VPNs as tools they use at home, but GlobalProtect is designed for business use. Employees sign in through their company, and GlobalProtect uses an online portal to configure their connection to the company’s network.
In 2025, researchers disclosed a cross-site scripting flaw in that browser-facing part of GlobalProtect. To use the flaw against someone, an attacker would first have to construct a poisoned link to the real VPN website. The link could carry attacker-controlled information along with the address itself, using the same general mechanism websites normally use to pass things like search terms, identifiers, or other values from one page to another.
That poisoned link still has to reach a person. An attacker would typically need some form of phishing or social engineering to get the user to click the link: an email that appears to come from work (see: email spoofing), a message claiming a VPN setting needs attention, a support conversation, or some other believable reason to click.
When the victim opens the link, they can still land on the real company VPN website. GlobalProtect reads information carried in the poisoned URL and includes it in the page it sends back to the browser. That behavior is not unusual, websites constantly read values from links and use them to decide what to display.
The failure happens in how that value is placed into the page. The attacker-controlled information should remain ordinary text, or an id that must be verified, or a general setting, but something no more powerful than something typed into a form field. But if the site inserts it into the page in a way the browser interprets as HTML, characters supplied by the attacker can stop being treated simply as text and start being treated as instructions that shape the page and can cause JavaScript to run. The poisoned part entered through the link and was then accidentally promoted from data into code by the trusted website itself.
Jira give us another example of the same problem taking a different route. In 2021, Atlassian disclosed a flaw where attacker-controlled project-related data could be saved and left behind. Later, when an administrator opened the affected Associated Projects page, that stored value could be interpreted by the browser as executable content.
That is stored XSS: the attacker plants the malicious content first, the website keeps it, and somebody else triggers it later simply by loading the page where it appears.
There are other forms of XSS too, but the list is broad, and the majority of the details are only relevant to developers. In a perfect world, developers prevent these types of attacks in the first place, but the reality is that mistakes do happen. Users should be aware of the links they are opening and the potential threat of phishing attacks and social engineering attacks.
That gets us to the basic idea behind cross-site scripting, usually shortened to XSS. Information that should have remained ordinary data is allowed to become executable code inside a website people trust.
Browsers normally try to keep websites separated from each other. A page on one website should not be able to simply read private information from another website or use another site's signed-in access. XSS gets around that protection in a different way: the vulnerable website itself causes attacker-controlled code to run as part of its own page.
Once the browser is running that code as part of the trusted page, the consequences become much more concrete. It may be able to read information already displayed on the page, watch or change form fields, replace buttons and links, send information somewhere else, and much more. The browser can attach the user's login session to those requests automatically, which means the malicious code may be able to perform actions using the user's account even without knowing their password.
If the person who triggers the malicious code is signed in as an administrator, it may be able to use that same authority. Depending on what the site allows, that could mean changing the account password, creating an API key or access token, or adding another administrator. The attacker may not need to know the administrator's password at all because the browser is already signed in and authorized to perform those actions.
An XSS attack does not necessarily have to end with the website where it started. The compromised service may itself have connections to other systems, or it may control information that will eventually be opened somewhere else. That can turn one successful XSS attack into a stepping stone for another attack.
A bookmark manager is an especially interesting example because its job is to store links and put them in front of people later. Malicious code running with access to a bookmark account could potentially change saved links, add new ones, modify shared Collections, or plant specially constructed URLs that target vulnerabilities in other services. If those links are synchronized or shared with other people, the attacker may even gain a new delivery mechanism. The second website would still need its own weakness for another XSS attack to succeed, but compromising the bookmark manager could give the attacker a trusted place from which to prepare and distribute those attacks.
At this point, bookmark managers become an interesting security case of their own. Their entire job is to accept links from people, save them, sync them, import them, and sometimes share them with somebody else. A Collections feature goes a step further: a link created or controlled by one person can end up in front of another person's browser.
That means links cannot always be treated as boring strings of text. A bookmark manager may look like a fairly simple application to build, but once it accepts user-controlled links and moves them between accounts, imports, or shared Collections, URL handling becomes a real security boundary. Small and newly built bookmark managers need to think about this just as seriously as larger ones do.
JavaScript bookmarks make that boundary especially clear. Browsers have supported them for a long time. Instead of storing an ordinary destination such as https://example.com, a bookmarklet stores JavaScript and runs it when the person deliberately opens the bookmark. They can be extremely useful for changing a page, extracting information, or starting an automation.
Inside a browser's built-in bookmark system, this has been exploited in the past too, but it's through a very different mechanism, usually involving malware. In that case, the threat comes from software that has already gained access to the browser. A web-based bookmark manager has a different problem to solve because JavaScript or poisoned links can arrive through several otherwise legitimate paths. Did it come from the account owner? Was it imported? Did it come from a shared Collection? Was it pasted from an untrusted website?
This is something we have spent a lot of time thinking about at WebCull. Simply refusing to support JavaScript bookmarks is an easy security answer, and for a long time it was a very reasonable one. But bookmarklets are also genuinely useful. I increasingly use WebCull as part of development and automation workflows myself, and small pieces of JavaScript can be an extremely powerful way to connect a bookmark to an action.
So instead of treating JavaScript bookmarks like ordinary links, WebCull puts them behind a separate security system. JavaScript in your own bookmarks starts disabled. JavaScript supplied through public Collections has a completely separate permission, and that starts disabled too. Turning on one does not turn on the other.
When one of those permissions is off and you deliberately open a JavaScript bookmark, WebCull stops and gives you a choice. You can cancel, use Run once without leaving the permission enabled, or explicitly allow that class of JavaScript for future deliberate opens. If you enable the permission, later bookmarks in that same trust category can run when you deliberately open them without another warning, so enabling it is a meaningful security decision rather than a cosmetic preference.
JavaScript bookmarks are also never allowed to open automatically, even after the matching permission has been enabled. On the WebCull web app, an allowed bookmarklet runs in the current WebCull page, which is exactly why we treat the feature as powerful and label these controls Less secure.
The public Collection boundary matters even more because the code may have been supplied by somebody else, and a Collection owner or collaborator may be able to change what is saved there later. That is why public Collection JavaScript has its own permission instead of inheriting permission from bookmarks you control yourself.
This is also a useful thing to examine when evaluating any bookmark manager or link-collection tool. Ask what happens when somebody saves a javascript: bookmark. Ask whether shared links can become executable code, whether JavaScript can open automatically, and whether code supplied by somebody else is separated from code you saved yourself. A tool that stores private information and accepts user-controlled links has to treat those boundaries as part of its security model, not as an edge case.
For people using the web, poisoned links are still the more practical warning to keep in mind. They are deliberately constructed to exploit a weakness in a real website and are commonly delivered through phishing or other social engineering designed to make the click feel normal. The danger is not that ordinary links are inherently unsafe. It is that a malicious link can point to a real website and still carry attacker-controlled information intended to trigger a flaw there. Being asked to paste or run code from somebody is a huge warning sign. Even clicking links from somewhere untrusted can be something you should avoid.
If you think you opened a poisoned link, do not rely on the page looking suspicious. A successful XSS attack can be completely invisible while code runs in the background using access your browser already has. If you have reason to believe a link was malicious, follow that service's security or account-recovery guidance. Signing out of active sessions, reviewing recent account activity, and changing credentials that may have been exposed are reasonable precautions when they apply. If the problem is an actual XSS flaw, only the website operator can fix the vulnerability itself.
The GlobalProtect and Jira flaws above were publicly disclosed vulnerabilities. Their public reports did not document confirmed in-the-wild exploitation, so they are useful examples of how these attacks can work rather than accounts of known breaches. The OWASP Cross Site Scripting Prevention Cheat Sheet provides a much deeper technical reference for people building websites.
If you use JavaScript bookmarks in WebCull, read the JavaScript Bookmarks documentation. It explains the separate permissions, the Run once option, and the trust checks to make before opening one.