How-to guides
Directions for a specific goal.
- Log users in Add a sign-in page with wicket-auth-roles, send anonymous users there when a page needs a signed-in user, and sign them out again.
- Restrict access by role Allow pages, components, actions and resources only for users with a given role, with annotations on classes and packages or in code.
- Require HTTPS Serve pages over HTTPS with HttpsMapper and @RequireHttps, and set up the container so redirects and absolute URLs use the right host.
- Protect against cross-site request forgery Refuse link clicks, form submits and Ajax calls that another site makes on behalf of your users, with ResourceIsolationRequestCycleListener.
- Configure the Content Security Policy Work with the strict Content Security Policy Wicket sends by default, allow extra sources, report violations, and move inline scripts and styles out of the markup.
- Isolate the page with COOP and COEP Set the Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers, which Wicket sends by default, to isolate your pages from other origins.
- Control which package resources are served Allow or block files on the classpath that browsers may request as package resources, with patterns on SecurePackageResourceGuard.
Reference
The classes, tags and settings, described.
- Encryption in Wicket The crypt API behind encrypted URLs, the encrypted page store and upload tokens; its schemes, key factories, settings and ciphertext format.
- Security headers and external checks The response headers that scanners such as Mozilla Observatory check, which of them Wicket sends by default, and the Wicket API or hook that sets each one.
Explanation
Why Wicket works the way it does.
- How Wicket keeps applications secure What Wicket defends against by default (escaping, a strict CSP, stateful URLs and encryption) and what it leaves to your application and your deployment.