Securing Your Tobesee Installation: Authentication, Tokens, and Best Practices

Security is not optional, even for a simple content website. Tobesee has a smaller attack surface than traditional CMS platforms because it has no database, but there are still areas that need attention. This article covers the security model, common threats, and practical steps to keep your installation safe.

How Tobesee Authentication Works

Tobesee uses a password-based login system protected by JWT (JSON Web Tokens). Here is the flow:

1. You navigate to /admin and enter your access password
2. The server compares your input against the ACCESS_PASSWORD environment variable
3. If the password matches, the server creates a JWT signed with JWT_SECRET
4. The JWT is stored in a secure, HTTP-only cookie in your browser
5. Subsequent requests to admin pages include this cookie automatically
6. The server verifies the JWT signature on each request

This approach is stateless — the server does not need to store session data. The JWT contains enough information to verify your identity, and the signature ensures it has not been tampered with.

Understanding the Threat Model

What Tobesee Does Not Have

• No database — SQL injection is impossible
• No user registration — no password database to breach
• No file uploads — no upload-based exploits
• No plugin system — no third-party code vulnerabilities

What Needs Protection

• Admin panel — unauthorized access could modify your content
• GitHub token — if leaked, an attacker could read and write to your repository
• JWT secret — if leaked, an attacker could forge admin tokens
• Environment variables — contain all sensitive credentials

Protecting the Admin Panel

Strong Password

Your ACCESS_PASSWORD is the first line of defense. Use a password that is:

• At least 16 characters long
• Generated randomly (use a password manager)
• Not used anywhere else
• Not based on dictionary words or personal information

Rate Limiting

Tobesee does not include built-in rate limiting for login attempts. If you are concerned about brute force attacks, consider adding rate limiting at the hosting level. Vercel supports this through Edge Middleware:

// middleware.ts
import { NextResponse } from 'next/server';

export function middleware(request) {
  // Add rate limiting logic for /api/login
  if (request.nextUrl.pathname === '/api/login') {
    // Implement rate limiting here
  }
  return NextResponse.next();
}

Alternatively, use Cloudflare or another CDN with built-in rate limiting in front of your site.

Session Expiration

JWT tokens should have a reasonable expiration time. A 24-hour expiration balances convenience (you do not need to log in constantly) with security (stolen tokens become useless after a day).

Check your Tobesee configuration to ensure JWT expiration is set appropriately.

Protecting Your GitHub Token

The GitHub personal access token is the most sensitive credential in your Tobesee setup. If compromised, an attacker could:

• Read all content in your repository
• Modify or delete articles and resources
• Access other repositories if the token has broad permissions

Minimize Token Permissions

When creating your token, only grant the repo scope. Do not grant:

• admin:org — organization management
• delete_repo — repository deletion
• admin:repo_hook — webhook management
• user — profile access

If you use fine-grained tokens (recommended), scope the token to your specific repository with only Contents read/write access.

Set Token Expiration

Classic tokens can be set to expire after 30, 60, or 90 days. Set an expiration and create a calendar reminder to rotate the token before it expires.

Fine-grained tokens require an expiration date by default, which is a security improvement.

Monitor Token Usage

GitHub provides an audit log for personal access tokens. Periodically check:

• When the token was last used
• Which IP addresses used it
• Whether any unexpected activity occurred

If you see suspicious activity, revoke the token immediately and generate a new one.

HTTPS Enforcement

All traffic to your Tobesee site should use HTTPS. This protects:

• Login credentials from being intercepted
• JWT cookies from being stolen
• Content from being modified in transit

Vercel provides HTTPS automatically with free SSL certificates from Let's Encrypt. If you use a custom domain, Vercel provisions the certificate automatically after DNS verification.

Verify HTTPS is working by checking that:

• Your site redirects HTTP to HTTPS
• The browser shows a lock icon in the address bar
• No mixed content warnings appear in the browser console

Environment Variable Security

Never Commit Secrets

Your .env.local file must never be committed to Git. Verify it is in .gitignore:

git check-ignore .env.local

If you accidentally commit secrets:

1. Immediately rotate all exposed credentials
2. Remove the file from Git history (use git filter-branch or BFG Repo-Cleaner)
3. Force push the cleaned history

Use Platform-Level Storage

On Vercel, environment variables are encrypted at rest and injected at runtime. They are never exposed in build logs or client-side code (unless prefixed with NEXT_PUBLIC_).

Never log environment variables in your application code, even for debugging.

Separate Environments

Use different credentials for development and production:

• Different GitHub tokens (ideally pointing to different repositories)
• Different JWT secrets
• Different admin passwords

This containment strategy limits the blast radius if any single credential is compromised.

Content Security Headers

Add security headers to your Tobesee site through next.config.js or Vercel configuration:

// next.config.js
const securityHeaders = [
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-XSS-Protection', value: '1; mode=block' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];

These headers protect against:

• MIME type sniffing attacks
• Clickjacking (embedding your site in iframes)
• Cross-site scripting (XSS)
• Referrer information leakage

Dependency Security

Regular Audits

Run npm audit periodically to check for known vulnerabilities in your dependencies:

npm audit

Fix critical and high-severity issues promptly. Low-severity issues can be addressed during regular maintenance.

Keep Dependencies Updated

Update dependencies quarterly:

npm update

For major version updates, test thoroughly before deploying. Breaking changes in dependencies can cause build failures or runtime errors.

Incident Response

If you suspect a security breach:

1. Rotate all credentials immediately — GitHub token, JWT secret, admin password
2. Check GitHub commit history — look for unauthorized changes to your content
3. Review Vercel deployment logs — check for unexpected deployments
4. Update environment variables on all platforms
5. Redeploy your application with the new credentials

Summary

Tobesee security model is simpler than traditional CMS platforms because there is no database, no user registration, and no plugin system. Focus your security efforts on protecting the admin panel with a strong password, managing your GitHub token carefully, enforcing HTTPS, and keeping dependencies updated. These straightforward practices provide strong protection for a content website.