There are different issues of "is this an honest interviewee?" and "is this a
good interview?" and you're welcome to argue the latter all you like but the solution to a bad interviewer isn't just to cheat because you don't like it.
Context matters. If you're looking to see "have you really done security stuff?" by mentioning some OWASP Top 10 vulns and asking for a quick description, for somebody that has indeed done any security at all that will be trivially easy and anybody else will need to google it. Can they skim google and get you an intelligeable answer? Maybe but that's not what you're looking for, the question itself is a proxy for something else.
For most of my interviews I tell folk up front to google whatever they need to. But at the very very earliest stage of the interview loop we do a quick "programmer is a big field, what kind are you?" round so we know how to place people and the questions we use for it are all trivially easy for somebody even remotely familiar with the fields we're looking at and also trivially googleable for anybody else. The goal with that piece isn't to challenge people it's just to round their skillset to the nearest role that we have. I've caught people retyping code, pretending to be inventing it, from what's clearly the first article they found when they googled the keywords. It was never intended to be a hard problem, just something to quickly tell an infrastructure from a frontend engineer. It was more or less bitwise identical to the article they were retyping from and they couldn't explain the code or modify it. That doesn't even accomplish what they want, even if it worked we'd then go on to interview them for a job they couldn't do.
Again you can argue about whether that's a good practise or not but it's still not licence to simply cheat on it. You're conflating these and and I think it's not the right thing to do.