URLs don't have "folders". URLs are not filesystem paths - they just happen to have a similar syntax plus a convention that when the webapp cannot figure out anything else to do with a URL, it disassembles it into a resource path in the WAR. Which may or may not be an actual physical file location, depending on whether the WAR was exploded by the appserver or not.
Having disposed with the pedantry: You can specify a URL pattern that demands secure transport by defining it in web.xml. This DOESN'T protect a "folder", only the URL pattern. If there's some other URL that can also access the resource in question, a separate pattern would have to be defined to restrict it as well.
This protection mechanism is almost identical with JSF as it is with non-JSF with one very critical exception. As you are probably well aware, the URL in the browser toolbar doesn't track the resources being accessed - it tends to lag. Recall, however, that the protection is for the URL, not the "folder", and you can see a problem.
The way to avoid this problem is simple: when navigating to a protected resource in JSF, add the "redirect" element to the navigation rules. That will force the URL to track the resource path by forcing a redirection.
Customer surveys are for companies who didn't pay proper attention to begin with.