fix links

pages/csrf.md

@@ -57,7 +57,7 @@ For the common token based approach, the token should not be single-use (e.g. a
 
 ### Anti-CSRF tokens
 
-This is a very simple method where each session have a unique CSRF [token](/server-side-tokens.md) associated with it.
+This is a very simple method where each session have a unique CSRF [token](/server-side-tokens) associated with it.
 
 ```html
 <form method="post">
@@ -71,7 +71,7 @@ This is a very simple method where each session have a unique CSRF [token](/serv
 
 If storing the token server-side is not an option, signed double submit cookies is another approach. This is different from the basic double submit cookie in that the token included in the form is signed with a secret.
 
-A new [token](/server-side-tokens.md) is generated and hashed with HMAC SHA-256 using a secret key.
+A new [token](/server-side-tokens) is generated and hashed with HMAC SHA-256 using a secret key.
 
 ```go
 func generateCSRFToken() (string, []byte) {

pages/email-verification.md

@@ -45,7 +45,7 @@ All sessions of a user should be invalidated when their email is verified.
 
 ## Email verification links
 
-An alternative way to verify emails is to use a verification link that contains a long, random, single-use [token](/server-side-tokens.md).
+An alternative way to verify emails is to use a verification link that contains a long, random, single-use [token](/server-side-tokens).
 
 ```
 https://example.com/verify-email/<TOKEN>
@@ -59,7 +59,7 @@ All sessions should be invalidated when the email is verified.
 
 ## Changing emails
 
-The user should be asked for their password, or if [multi-factor authentication](/mfa.md) is enabled, authenticated with one of their second factors. The new email should be stored separately from the current email until it's verified. For example, the new email could stored with the verification token/code.
+The user should be asked for their password, or if [multi-factor authentication](/mfa) is enabled, authenticated with one of their second factors. The new email should be stored separately from the current email until it's verified. For example, the new email could stored with the verification token/code.
 
 A notification should be sent to the previous email address when the user changes their email.
 

pages/mfa.md

@@ -85,13 +85,13 @@ Throttling must be implemented. A basic example is blocking attempts for 15 to 6
 
 ## SMS
 
-We discourage SMS based MFA as it can be intercepted and unreliable at times. However, it may be more accessible than using authenticator apps. See the [Email verification code](/email-verification.md#email-verification-codes) guide for a guideline on implementing verification codes. The code should be valid for around 5 minutes.
+We discourage SMS based MFA as it can be intercepted and unreliable at times. However, it may be more accessible than using authenticator apps. See the [Email verification code](/email-verification#email-verification-codes) guide for a guideline on implementing verification codes. The code should be valid for around 5 minutes.
 
 Throttling must be implemented. A basic example is blocking attempts for 15 to 60 minutes after the 5th consecutive failed attempt. The user should also be notified to change the password as well.
 
 ## Passkeys
 
-Passkeys allow you to use in-device authentication methods, such as biometrics and pin-codes. See the [Passkeys](/passkeys.md) guide.
+Passkeys allow you to use in-device authentication methods, such as biometrics and pin-codes. See the [Passkeys](/passkeys) guide.
 
 ## Recovery codes
 

pages/oauth.md

@@ -168,4 +168,4 @@ Account linking allows users to sign in with any of their social accounts and be
 
 ## Other considerations
 
-- [Open redirect](/open-redirect.md).
+- [Open redirect](/open-redirect).

pages/passkeys.md

@@ -13,13 +13,13 @@ title: "Passkeys"
 
 ## Overview
 
-Passkeys are built on top the [Web Authentication (WebAuthn) standard](https://www.w3.org/TR/webauthn-2/) and allows applications to authenticate users with in-device authentication methods, including biometrics and device pin-code. It can be more secure than traditional passwords as it doesn't require the user to remember their passwords. It can replace passwords entirely or be used in addition to passwords as a [second factor](/mfa.md).
+Passkeys are built on top the [Web Authentication (WebAuthn) standard](https://www.w3.org/TR/webauthn-2/) and allows applications to authenticate users with in-device authentication methods, including biometrics and device pin-code. It can be more secure than traditional passwords as it doesn't require the user to remember their passwords. It can replace passwords entirely or be used in addition to passwords as a [second factor](/mfa).
 
 Passkeys are based on public key cryptography, where each user has a public-private key pair. The private key is stored in the user's device, while the public key is stored in your application. The device creates a signature with the private key and your application can use the public key to verify it.
 
 ## Challenge
 
-Each attestation and assertion has a challenge associated to it. A challenge is a randomly generated single-use [token](/server-side-tokens.md) stored in the server for preventing replay attacks. The recommended minimum entropy is 16 bytes.
+Each attestation and assertion has a challenge associated to it. A challenge is a randomly generated single-use [token](/server-side-tokens) stored in the server for preventing replay attacks. The recommended minimum entropy is 16 bytes.
 
 ## Registration
 

pages/password-authentication.md

@@ -119,7 +119,7 @@ Passwords are susceptible to brute-force attacks. There are mainly 2 approaches
 1. The attacker tries a bunch of common passwords.
 2. The attacker targets specific accounts using leaked passwords (credential stuffing).
 
-[Multi-factor authentication (MFA)](/mfa.md) is the best defense against brute-force attacks. While it doesn't prevent brute-force attacks themselves, it does make it near pointless to do. Users should be recommended to enable MFA and it should be required for security-critical applications.
+[Multi-factor authentication (MFA)](/mfa) is the best defense against brute-force attacks. While it doesn't prevent brute-force attacks themselves, it does make it near pointless to do. Users should be recommended to enable MFA and it should be required for security-critical applications.
 
 IP-based throttling should always be implemented. A basic example is to block all attempts from an IP address for 10 minutes after they fail 10 consecutive attempts. Other ideas include increasing the lockout period on each lockout, and gradually allowing new attempts at a set interval after a lockout. This also prevents DOS attacks as password hashing is resource-intensive. An identifier-based throttling can also be implemented on top of IP-based throttling, though this can introduce DoS vulnerabilities (see [device cookies](https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies)).
 
@@ -137,4 +137,4 @@ Even when returning a generic message, it may be possible to determine if a user
 
 - Do not prevent users from copy-pasting passwords as it discourages users from using password managers.
 - Ask for the current password when a user attempts to change their password.
-- [Open redirect](/open-redirect.md).
+- [Open redirect](/open-redirect).

pages/password-reset.md

@@ -12,7 +12,7 @@ title: "Password reset"
 
 ## Overview
 
-A common approach to password reset is to use the user's email address. The user enters their email and, if the email is valid, a password reset link is sent to the mailbox. This requires each user to have a unique email address - see the [Email verification](/email-verification.md) guide.
+A common approach to password reset is to use the user's email address. The user enters their email and, if the email is valid, a password reset link is sent to the mailbox. This requires each user to have a unique email address - see the [Email verification](/email-verification) guide.
 
 The email does not need to be verified before sending a reset link. You should even mark a user's email address as verified if they reset their password.
 
@@ -26,7 +26,7 @@ Password reset requires 2 pages. First is the page where users enter their email
 https://example.com/reset-password
 ```
 
-Next is the actual password reset form, where the user enters their new password. This is the link that gets sent to the user's mailbox. A password reset [token](/server-side-tokens.md) is included as part of the URL path.
+Next is the actual password reset form, where the user enters their new password. This is the link that gets sent to the user's mailbox. A password reset [token](/server-side-tokens) is included as part of the URL path.
 
 ```
 https://example.com/reset-password/<TOKEN>
@@ -38,7 +38,7 @@ The token must be single-use. Delete the token when the user sends a valid passw
 
 Make sure to set the pages's [Referrer Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) tag to `noreferrer` to protect the token from referer leakage.
 
-If the user has implemented [multi-factor authentication](/mfa.md), such as via authenticator apps or passkeys, they should be prompted to authenticate using their second factor before entering their new password.
+If the user has implemented [multi-factor authentication](/mfa), such as via authenticator apps or passkeys, they should be prompted to authenticate using their second factor before entering their new password.
 
 ## Rate limiting
 

pages/server-side-tokens.md

@@ -28,7 +28,7 @@ For single-use tokens, any retrieval should also guarantee deletion. In SQL for
 
 ## Generating tokens
 
-Tokens should have at least 112 bits of entropy (120-256 is a good range). For example, you could generate 15 random bytes and encode it with base32 to get a 24 character token. If you generate tokens by choosing random characters one-by-one, you should ensure a similar level of entropy. See the [Generating random values](/random-values.md) page for more information.
+Tokens should have at least 112 bits of entropy (120-256 is a good range). For example, you could generate 15 random bytes and encode it with base32 to get a 24 character token. If you generate tokens by choosing random characters one-by-one, you should ensure a similar level of entropy. See the [Generating random values](/random-values) page for more information.
 
 Tokens must be generated using a cryptographically-secure random generator. Fast, pseudo-random generators like those generally provided by standard math packages should be avoided for this.
 

pages/sessions.md

@@ -22,7 +22,7 @@ Throughout a user's visit to your website, they will make multiple requests to y
 
 Sessions are a way to persist state in the server. It is especially useful for managing authentication state, such as the client's identity. We can assign each session with a unique ID and store it on the server to use it as a token. Then the client can associate the request with a session by sending the session ID with it. To implement authentication, we can simply store user data alongside the session.
 
-It's important that the session ID is sufficiently long and random, or else someone could impersonate other users by just guessing their session IDs. See the [Server-side tokens](/server-side-tokens.md) guide for generating secure session IDs. Session IDs can be hashed before storage to provide an extra level of security.
+It's important that the session ID is sufficiently long and random, or else someone could impersonate other users by just guessing their session IDs. See the [Server-side tokens](/server-side-tokens) guide for generating secure session IDs. Session IDs can be hashed before storage to provide an extra level of security.
 
 Depending on your application, you may only have to manage sessions for authenticated users, or for both authenticated and unauthenticated users. You can even manage 2 different kinds of sessions - one for auth and another for non-auth related state.
 
@@ -85,7 +85,7 @@ Session cookies should have the following attributes:
 - `Max-Age` or `Expires`: Must be defined to persist cookies
 - `Path=/`: Cookies can be accessed from all routes
 
-[CSRF protection](/csrf.md) must be implemented when using cookies, and using the `SameSite` flag is not sufficient. Using cookies does not automatically protect your users from cross-site scripting attacks (XSS) as well. While the session ID can't be read directly, authenticated requests can still be made as browsers automatically include cookies in requests. 
+[CSRF protection](/csrf) must be implemented when using cookies, and using the `SameSite` flag is not sufficient. Using cookies does not automatically protect your users from cross-site scripting attacks (XSS) as well. While the session ID can't be read directly, authenticated requests can still be made as browsers automatically include cookies in requests. 
 
 The maximum expiration for a cookie is anywhere between 1 and 2 years. If you plan for the session to be long-lived, continuously set the cookie on a set interval (e.g. when you extend the session expiration).