SecureServer is a Python-based web application security framework and example application focused on making it easier to build secure web applications.
It provides a collection of authentication, encryption, session-management, validation, security-header, logging, and administration features that can be integrated into Python web applications.
The repository includes an example application called Secure Vault, a JavaScript/HTML/CSS frontend, a Python backend built around FastAPI, and a Windows administrator portal written in C#.
Current version: v5.1.3
Platform: Windows 10/11
Primary language: Python
SecureServer is a personal security-focused project and has not undergone professional penetration testing or a formal security audit.
The project implements many common security mechanisms, but passing basic security checks does not mean that the system is secure against all attacks.
Do not use SecureServer to protect sensitive production data without independently reviewing, testing, and hardening the implementation.
In particular:
- No guarantee of complete security is provided.
- No professional penetration test has been performed.
- Cryptographic implementations should be independently reviewed before production use.
- Configuration and deployment security are the responsibility of the application developer.
- Secrets must never be committed to a public repository.
- The example application should be treated as a demonstration rather than a production-ready vault.
SecureServer currently provides functionality for:
- Username/password authentication
- Password strength requirements
- PBKDF2-HMAC-SHA256 password hashing
- Login attempt tracking
- Account lockout after repeated failed logins
- Session management
- Authentication tokens
- Token expiration
- Secure token hashing
- Logout and forced logout functionality
- Password changes
- Re-authentication windows
SecureServer supports optional TOTP-based 2FA.
Features include:
- TOTP secret generation
- QR-code generation
- OTP verification
- Optional 2FA for new accounts
- Optional requirement for all accounts
2FA behavior is controlled through environment variables.
SecureServer uses cryptographic primitives provided by Python's cryptography ecosystem rather than implementing AES directly.
The project currently uses:
- AES-GCM for authenticated encryption
- PBKDF2-HMAC-SHA256 for password-derived keys
- SHA-256 for key derivation
- SHA3-256 for basic hashing
- HMAC-SHA256 for token hashing/integrity operations
- Random nonces for AES-GCM encryption
- Random salts for password hashing
Passwords are not stored in plaintext.
Password hashes are generated using PBKDF2 with a randomly generated salt and a high iteration count.
SecureServer stores application data in local files rather than requiring a traditional database.
Important data files include:
backend/SecureServer/data/
├── users.json
├── tokens.json
└── failed_attempts.json
The application provides encrypted/integrity-protected storage functions for these files.
User data additionally includes an integrity signature so that modifications to stored data can be detected.
If enabled, corrupted data files can automatically be replaced with fresh data.
This behavior is controlled by:
REPLACE_CORRUPTED_FILES
For security-sensitive deployments, automatically replacing corrupted security data should be considered carefully because corruption can be an indicator of tampering.
SecureServer maintains server-side session information for authenticated users.
Sessions contain information needed to validate the authentication state and have a configurable lifetime.
The session store includes:
- Session IDs
- Login-derived secrets
- Expiration timestamps
- Thread-safe access
- Automatic expiration cleanup
The default session lifetime is 3600 seconds.
Authentication information is stored using cookies.
The system supports:
- HTTP-only authentication cookies
- Secure cookies when HTTPS is enabled
- SameSite restrictions
- CSRF tokens
- Short-lived authentication tokens
Authentication tokens are hashed before being stored by the server.
The authentication system also uses an additional encrypted authentication value to validate the user's active session.
State-changing requests can require a CSRF token.
The server compares the token supplied in the request header against the CSRF value associated with the authenticated session.
Clients can send:
X-CSRF-Token: <token>This provides an additional layer of protection against cross-site request forgery.
SecureServer automatically adds several HTTP security headers.
The current middleware includes:
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Strict-Transport-SecurityThe Content Security Policy currently restricts scripts to the application's own origin:
script-src 'self'
and prevents the application from being embedded in frames.
The server also provides optional HTTPS redirection.
HTTPS support can be enabled through configuration.
Relevant settings include:
USE_HTTPS
SSL_CERT_FILE
SSL_KEY_FILE
SSL_CIPHERS
HTTPS_HOST
HTTPS_PORT
When HTTPS enforcement is enabled, HTTP requests can be redirected to HTTPS.
For production deployments, HTTPS should be configured using a properly issued certificate and a correctly secured private key.
SecureServer uses Pydantic models to validate incoming API data.
For example, account creation validates:
- Username length
- Username characters
- Password length
- Password complexity
- Optional personal information
Passwords must contain:
- At least one uppercase character
- At least one lowercase character
- At least one number
- At least one punctuation/special character
The default password length requirement is 12-72 characters.
The authentication system tracks failed login attempts.
Configurable settings include:
MAX_LOGIN_FAILURES
LOCKOUT_LOGIN_WINDOW
For example:
MAX_LOGIN_FAILURES=5
LOCKOUT_LOGIN_WINDOW=900
would allow five failed attempts before the configured lockout period is applied.
This functionality is intended to reduce the effectiveness of repeated password-guessing attempts.
SecureServer includes administrative functionality for managing users and sessions.
The backend contains administrative operations for:
- Listing users
- Creating users
- Listing login attempts
- Listing sessions
- Clearing login attempts
- Logging out users
- Logging out all sessions
- Promoting users to administrators
- Removing administrator privileges
Administrative functionality is protected separately from ordinary authenticated users.
The repository also contains a Windows administrator application:
backend/SecureServerAdminPortal.exe
The source code is included in:
backend/SecureServerAdminPortal_source/
The administrator portal is written in C# using Windows Forms.
The source project includes components for:
- Administrator login
- OTP verification
- User management
- Session management
- Login-attempt viewing
- Server log viewing
- User creation
- Dark-mode UI components
The Visual Studio project is:
ServerLogViewer.csproj
SecureServer includes a centralized logging system.
Logs are written to:
backend/SecureServer/server.log
The logging system uses a rotating file handler.
The current configuration allows:
- 10 MB per log file
- Up to 5 backup files
The logging system also attempts to sanitize:
- ANSI escape sequences
- Control characters
- Newlines
- Carriage returns
This helps reduce the risk of log-injection-style attacks and keeps logs easier to interpret.
The repository contains a demonstration application called Secure Vault.
The frontend provides:
- Account creation
- Login
- Optional 2FA
- Dashboard
- Personal information
- Encrypted vault storage
- Password changing
- Logout
- Administrative user viewing
The example frontend is located in:
frontend/
The primary pages are:
frontend/
├── index.html
├── login.html
├── signup.html
├── dashboard.html
├── change-password.html
└── style.css
JavaScript functionality is located in:
frontend/code/
SecureServer uses a .env file for configuration.
Important environment variables include:
APP_NAME=YourAppName
SERVER_HOST=127.0.0.1
SERVER_PORT=8000
HTTPS_HOST=0.0.0.0
HTTPS_PORT=443The following keys are required:
SYSTEM_KEY=
INTEGRITY_KEY=
ENCAPSILATION_KEY=
TOKEN_KEY=These values should be generated using cryptographically secure random data.
For example:
python -c "import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())"Generate a different value for every key.
Never commit these values to source control.
USE_HTTPS=False
MAX_LOGIN_FAILURES=5
LOCKOUT_LOGIN_WINDOW=900
TOKEN_AGE=900
PW_CHANGE_AUTH_WINDOW=1202FA can be configured using:
ENABLE_2FA=False
REQUIRE_2FA=False
DEFAULT_USER_2FA=FalseFor example:
ENABLE_2FA=True
REQUIRE_2FA=Truecan be used to enable and require 2FA.
The signup system can optionally collect:
DEFAULT_USER_TAKE_FULL_NAME=True
DEFAULT_USER_TAKE_EMAIL=False
DEFAULT_USER_TAKE_PHONE=FalseEmail and phone functionality can also be configured through the SMTP and Twilio settings.
SecureServer contains support for SMTP notifications.
Example configuration:
SMTP_SERVER=smtp.gmail.com
SMTP_PORT=587
SMTP_USERNAME=
SMTP_PASSWORD=
FROM_EMAIL=Do not store real email passwords or API credentials in source control.
SMS notifications can be configured using Twilio:
TWILIO_ACCOUNT_SID=
TWILIO_AUTH_TOKEN=
TWILIO_PHONE_NUMBER=git clone <repository-url>
cd secureServerWindows:
python -m venv .venvActivate it:
.venv\Scripts\activateInstall the required Python packages used by the project, including the project's FastAPI, cryptography, environment-variable, and TOTP dependencies.
If a dependency file is added to the project in the future, install it with:
pip install -r requirements.txtCreate/configure the backend environment file:
backend/.env
At minimum, configure:
SYSTEM_KEY=<random-secret>
INTEGRITY_KEY=<random-secret>
ENCAPSILATION_KEY=<random-secret>
TOKEN_KEY=<random-secret>Do not reuse these values across different installations.
From the backend directory:
cd backend
python main.pyOr you can open the SecureServerAdminPortal.exe file, and log in. Your initial log in will create the master admin.
The server configuration determines the host and port used by the application.
The default development configuration is:
http://127.0.0.1:8000
The included frontend is intended to be served by the SecureServer application.
The example application provides pages for:
/login.html
/signup.html
/dashboard.html
/change-password.html
The frontend communicates with the backend API using JavaScript fetch requests.
A typical login flow works approximately as follows:
User
│
│ username + password
▼
Login endpoint
│
├── Validate request
│
├── Check login attempts
│
├── Verify password
│
├── Optional 2FA
│
├── Create session
│
├── Generate authentication token
│
└── Set authentication cookies
│
▼
Authenticated Dashboard
For protected requests:
Browser
│
│ auth_token
│ auth_key
│ CSRF token
▼
SecureServer
│
├── Validate token
├── Validate session
├── Decrypt authentication value
└── Validate CSRF token
│
▼
Protected endpoint
SecureServer is intended to be reusable beyond the included Secure Vault example.
The basic idea is to use the authentication and security infrastructure provided by the backend while replacing the example application's frontend and application-specific endpoints.
The core functionality is primarily contained in:
backend/SecureServer/
while the example application is primarily represented by:
backend/main.py
frontend/
This allows SecureServer to serve as a starting point for other Python web applications requiring authentication and security infrastructure.
The project is primarily developed for Windows at the moment.
The intended development environment is:
Windows 10/11
Python
FastAPI
HTML
CSS
JavaScript
C# / Windows Forms
Linux support is planned for future versions.
The project focuses on several goals:
Use established security mechanisms such as authenticated encryption, password hashing, CSRF protection, secure cookies, input validation, and security headers.
Make common security functionality accessible without requiring every application to implement authentication infrastructure from scratch.
Keep authentication, encryption, logging, validation, sessions, and administration separated into individual modules.
Allow the Secure Vault example to eventually be replaced with other applications using the same security framework.
Keep the security-related implementation available in the repository so that the behavior can be inspected and reviewed.
SecureServer currently has several important limitations.
The project has not undergone professional penetration testing or a formal security audit.
User and session-related data is stored using local files rather than a production database.
The current project is primarily designed around Windows development and local/self-hosted deployments.
Weak environment variables, improperly configured HTTPS, exposed secrets, unsafe server configuration, or incorrect deployment can undermine the security mechanisms provided by the project.
Using established cryptographic libraries does not automatically make an application's cryptographic design secure. The complete design should be independently reviewed before handling sensitive information.
Created by Evan Hill
SecureServer is an educational and personal software project intended to explore secure web application development.
Disclaimer: SecureServer is not a professionally audited security framework.