Roughly speaking, there's two sorts of access restrictions that an NFS server can put on a client: what filesystems the client can access, and what directories in the filesystems the client can access (this is necessary when you export a subdirectory in the filesystem, instead of the whole filesystem).

(This ignores just firewalling off the client entirely. The NFS server code generally doesn't have any special handling for this, because from its perspective, not allowing someone to talk at all is functionally identical to not allowing them access to any filesystems.)

Per-filesystem access restrictions are generally very solid, because it is easy for the NFS server to tell what filesystem a client is trying to access; the information is generally directly present in the NFS filehandle and cannot be usefully altered by the client. The same is not true of directory restrictions, because most NFS servers do not have any good way of knowing if an inode (and thus an NFS filehandle) falls under a directory hierarchy, so the only way they have of enforcing this limit is by never letting you have a filehandle for something outside your allowed directory hierarchy.

This has two problems: first, we've already seen how well filehandle secrecy works in practice, and second, there have traditionally been any number of creative ways to trick an NFS server into letting you escape from your 'jail' and get a filehandle for somewhere else in the filesystem. Hence the traditional advice that you should always export whole filesystems, or at least not count on subdirectory restrictions for much security.

That the NFS server doesn't really know what directory hierarchy a filehandle falls under is also why you generally can't export two separate bits of the same filesystem to the same client with different options (one read-write, one read-only, for example). If the server allowed you to specify different options, it would have no way of figuring out which set to apply to a given filehandle.