Wouldn't it be trivial to keep the list of malicious pages locally and not send any data?
And also use the local client to scan unknown links? They probably dont want outsiders to have access to this code.
Dunning-Kruger level of understanding: Never trust the client for anything ever, it's unreliable, everything must be off client.
Never mind the client is literally the interface into your system, so it being compromised is already game over for an application where the user is most vulnerable party you wanted to protect...
Deep understanding: Trusting the client requires a well thought out security model.
If the client is hacked in this case, they already have full control over what the user sees, they can cut out your remote check.
Maybe a good balance would be to hash the root of the URLs and compare those, or use fuzzy hashing on page contents, just so that the backend isn't getting a bunch of private urls that might accidentally get logged somewhere.
Trades detecting stuff hidden behind redirects for less liability on your backend, something to possibly consider depending on functional requirements.
1. User opens Outlook and types in their email and password.
2. The app requests the user's password hash from the server and checks it.
3. Outlook tells the server auth was successful and gets a session token.
The client has a much bigger issue to worry about if the client-side malware scanning has been compromised. Malware could modify the UI/network calls such that your server-side scanning displays a positive result anyway.
You have to trust the client to display information to the user at some point. Link malware scanning that job can safely be delegated to the client. Authentication cannot.