The current version of Windows File Sharing (SMB v3) includes a number of good security features, but they are not all enabled by default. If you want to ensure your file share uses cryptographic protections (signing and encrypting), you should explicitly check (and enable if needed) those features. See https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-security for more info (it's written for Windows Server but the commands work on client SKUs too).
Without such protection (end-to-end encryption and signing/MAC), malicious devices can intercept your computers' network traffic by spoofing to each computer that they are the router (which will cause your computer to route all traffic through them, whatever its final destination, allowing the attacker to read and edit the data). This attack is called ARP Spoofing (or ARP Poisoning; ARP stands for Address Routing Protocol and has no inherent security) and most home routers have little if any protection against it.
Additionally, the way Windows authentication over the network usually works is not very secure. While a strong password will stop anybody from accessing the files casually, a knowledgeable and persistent attacker will have no trouble gaining access given a man-in-the-middle position on the network (obtainable via ARP spoofing, as before) and executing a "pass the hash" attack using a challenge obtained from the server and the response generated by the legitimate client in response to this challenge (see here for an explanation of SMB non-interactive authentication; in the absence of a domain controller - as here - the machine acting as the server stores the password hash and uses it to verify the response itself). The attacker could also just try brute-forcing the password, by capturing a challenge and its corresponding response and then guessing passwords and checking their hashes (the hashing algorithm used is weak, and a GPU can computer billions of candidate passwords' hashes per second; checking whether it encrypts the challenge correctly is an additional step but can also be done very quickly). A really, truly good password will resist this for quite some time, though.
There can also be weaknesses in SMB, or in other Windows services or third-party server software that are exposed on such a network, that an attacker could exploit. For example, there was a critical bug in Windows' Terminal Services (remote desktop server) a while ago; if you have RDP enabled and exposed through the firewall, and hadn't patched yet, it could have been used to take over your machine.
Don't forget about interception of other non-encrypted network communication, either! Malicious software with a network position like that can read all unencrypted network traffic, and edit or spoof all non-authenticated traffic. Anything from plain-text HTTP to many multiplayer games could be attacked this way. This of course applies any time you're on an untrusted network (any network that is shared with untrusted devices), regardless of firewall settings, Windows sharing, etc.
Finally, consider that malicious software in such a position can harm you indirectly by abusing your Internet connection. Everything from simply saturating the connection (because the compromised machine is participating in DDoS attacks or similar) to bringing legal trouble down on whoever owns the connection (due to uploading pirated media or other illegal content).
Enough about the risks; what can you do?
First, you can enable the SMB security features, as mentioned above. They're not a panacea, and they will prevent file or printer sharing with older Windows versions or most third-party SMB implementations, but they're generally a good idea and you did say both computers you care about run Win10.
Install patches and updates promptly (and reboot when required). Most of the big Windows worms happened months after a patch was available, exploiting machines that hadn't patched yet.
A much stronger security boundary, however, would be to block the untrusted machines entirely at the firewall. Block rules take precedence over allow rules, so even though you're allowing SMB on the network in general, those particular computers would still be unable to access it. However, reliably identifying specific computers on a network is hard (unless you implement a complicated scheme such as IPSec); computer names, IP addresses, and even MAC addresses are variable and can be changed / spoofed.
If you can, one of the best options would be to isolate your trusted machines from the untrusted ones. Some routers (generally all of the better ones) support multiple
"subnets", which can be isolated from one another; computers on a given subnet can talk to each other, and everybody can reach the Internet (unless you choose to block that too), but devices on one subnet can be prevented from accessing devices on another. This still has the authentication problem, but if you're using WiFi you can have multiple SSIDs (with different passwords) and use a different SSID than your roommates. Assuming your roommates aren't actively trying to compromise your system (via physical, "real-world" actions), and that you use secure passwords, that should be sufficient to prevent any malicious software on their machines from being able to access yours. However, you should also block the untrusted devices from accessing the router's admin console, and install any firmware updates available for the router (home routers in particular are notorious for gaping security flaws).
The only real fix, however, is to either secure the devices in question or kick them off the network entirely. I've written this answer under the assumption that neither of these is a practical option, but it's something you should look hard at. People don't generally want their devices to run malware; can you help your roommates secure their computers? Is there a known infection you can point out to them, with the steps to fix it (even if the fix is "reinstall the operating system, ideally to a version that won't end up unsupported soon")? Lacking that, if you own the network / Internet connection, it's reasonable to have a policy regarding the security of devices connecting to that network.