I want you to perform a comprehensive security audit and hardening of the entire website.
IMPORTANT:
Start with ANALYSIS + PLAN ONLY.
Do NOT modify, create, delete, rename, migrate, or overwrite any files during the initial analysis.
Do NOT immediately start fixing things.
First inspect the entire application, identify concrete security risks, explain their impact, and produce a remediation plan.
Then STOP and wait for my explicit approval before making ANY changes.
PRIMARY OBJECTIVE
Find and safely remediate security vulnerabilities across the entire application while preserving all existing functionality.
The goal is not to make arbitrary changes or simply add security code everywhere.
Only make changes that are justified by the actual project architecture and identified security risks.
1. FULL CODEBASE AUDIT
Inspect the entire repository and understand:
Next.js architecture
App Router / Pages Router if applicable
Server Components
Client Components
Server Actions
API routes
Middleware
Authentication
Authorization
Admin Panel
Database/ORM
Product system
Orders
Payments
Checkout
User profiles
File uploads
Image handling
Telegram integration
Telegram webhooks
Telegram bot
Queue/event system
Product publishing
Product button URLs
Custom emoji system
Localization
Environment variables
External APIs
Third-party integrations
Logging
Error handling
Caching
Cookies
Sessions
CSRF protections
Rate limiting
Deployment configuration
Search the entire repository for security-sensitive patterns instead of auditing only obvious files.
2. AUTHENTICATION
Audit authentication thoroughly.
Check for:
Weak authentication logic
Session fixation
Session theft
Insecure session storage
Missing session expiration
Insecure cookies
Missing Secure flag
Missing HttpOnly flag
Incorrect SameSite configuration
Password reset vulnerabilities
Email verification vulnerabilities
Account enumeration
Login brute force
Credential stuffing
Weak password handling
Passwords stored incorrectly
Tokens exposed to clients
Tokens appearing in URLs
Tokens appearing in logs
Improper logout
Authentication bypasses
Missing authentication on protected routes
Do not replace the existing authentication system unless absolutely necessary.
3. AUTHORIZATION / IDOR
Audit every protected operation.
Pay particular attention to:
Admin APIs
Product management
Product deletion
Product editing
Order access
User profile access
File access
Telegram management
Settings
Upload endpoints
Any API accepting IDs, slugs, filenames, or database identifiers
Check for:
IDOR
Broken access control
Privilege escalation
User-to-user data access
Admin endpoint exposure
Missing ownership checks
Client-side-only authorization
Authorization MUST be enforced server-side.
4. API SECURITY
Audit every API route.
Check:
Authentication
Authorization
Input validation
Schema validation
HTTP methods
Rate limiting
Request size limits
Error handling
Sensitive response data
Mass assignment
Parameter tampering
SQL/ORM injection
NoSQL injection if applicable
Command injection
Path traversal
SSRF
Open redirects
Unsafe URL fetching
Improper CORS
Missing security headers
Abuse of expensive endpoints
Identify APIs that can be called directly without going through the UI.
5. INPUT VALIDATION
Audit every user-controlled input.
This includes:
Product names
Product descriptions
Prices
Slugs
Usernames
Email addresses
Telegram usernames
URLs
Search queries
Category values
Admin settings
Form fields
Query parameters
JSON bodies
Headers where relevant
File metadata
Use strict server-side validation.
Prefer the project’s existing validation library if one exists.
Do not rely on frontend validation.
6. XSS
Search for:
dangerouslySetInnerHTML
raw HTML rendering
Markdown rendering
rich text
HTML templates
Telegram HTML
user-generated content
unsanitized descriptions
unsafe DOM manipulation
Check for:
Stored XSS
Reflected XSS
DOM XSS
Do not blindly remove legitimate HTML functionality.
Use context-appropriate sanitization/escaping.
7. SQL / DATABASE SECURITY
Audit database access.
Check for:
Raw SQL
Unsafe query construction
Dynamic SQL
Injection risks
Missing authorization before queries
Excessive data retrieval
Sensitive fields returned unnecessarily
Unsafe delete/update operations
Race conditions
Transaction problems
Missing uniqueness constraints
Mass assignment
Use parameterized queries and the existing ORM safely.
8. FILE UPLOAD SECURITY
This is especially important because the Admin Panel supports icons/images.
Audit every upload mechanism.
Check:
MIME validation
Extension validation
Magic-byte/file-signature validation
File size limits
Filename sanitization
Path traversal
SVG security
Image decompression bombs
Executable uploads
Script uploads
Double extensions
Content-Type spoofing
Public/private storage
Unauthorized file access
File overwrite vulnerabilities
Do not allow uploaded files to become executable code.
If SVG uploads are allowed, specifically analyze XSS risks.
9. URL / SSRF SECURITY
Find every place where the server accepts or fetches a URL.
Check for SSRF against:
127.0.0.1
private IP ranges
cloud metadata endpoints
internal services
Docker/network services
Also check:
Open redirects
URL parser bypasses
DNS rebinding risks
Protocol restrictions
Only allow safe protocols such as HTTPS where appropriate.
10. TELEGRAM SECURITY
Audit all Telegram functionality carefully.
Check:
Webhook authentication
Webhook secret/token validation
Telegram update validation
Admin authorization
Bot command authorization
Product publishing
Queue events
Event idempotency
Replay attacks
Duplicate processing
Telegram API credentials
Bot tokens
Environment variables
Telegram message data
Product URLs
External URLs
Do NOT break existing Telegram publishing, queue, emoji, or product-button functionality.
11. SECRETS
Search the repository for exposed secrets.
Look for:
API keys
Bot tokens
Database credentials
JWT secrets
Encryption keys
Private keys
OAuth secrets
Payment credentials
Hardcoded passwords
Check:
Source files
Config files
.env files
Git-tracked files
Client bundles
Logs
Error messages
NEVER expose server-only secrets to client-side code.
Do not print discovered secret values in your report.
Only identify the file/location and secret type, and redact sensitive values.
12. NEXT.JS SECURITY
Audit the Next.js configuration.
Check:
next.config
middleware
headers
redirects
rewrites
image configuration
server/client boundaries
environment variable exposure
caching
static generation
server actions
API routes
Review appropriate security headers such as:
Content-Security-Policy
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
Strict-Transport-Security
Frame protections
Do not add an overly restrictive CSP that breaks the existing application.
If CSP is appropriate, design it based on the actual resources used by the project.
13. CSRF
Determine whether CSRF protection is required for the application’s authentication/session architecture.
Check all state-changing operations:
POST
PUT
PATCH
DELETE
Server Actions
Do not add redundant or incompatible CSRF mechanisms if the existing architecture already provides equivalent protection.
14. RATE LIMITING / ABUSE
Identify endpoints vulnerable to automated abuse.
Prioritize:
Login
Registration
Password reset
Email verification
Checkout
Order creation
Product search
Contact forms
Uploads
Admin APIs
Telegram APIs
Expensive database operations
Recommend appropriate rate limits based on the endpoint.
Do not introduce rate limiting that would interfere with legitimate Telegram queue processing or normal customer usage.
15. BUSINESS LOGIC SECURITY
Audit for logic vulnerabilities, including:
Price manipulation
Quantity manipulation
Product ownership bypass
Order status manipulation
Payment status manipulation
Unauthorized refunds
Coupon abuse
Duplicate order creation
Replay attacks
Race conditions
Negative quantities
Invalid prices
Client-controlled trusted values
Admin-only fields being modified by clients
Never trust prices, permissions, order status, or other sensitive values supplied by the browser.
16. ERROR HANDLING
Check whether errors expose:
Stack traces
Database details
File paths
Environment variables
API keys
Internal service information
SQL queries
Debug information
Production responses should expose safe error messages while detailed diagnostics remain server-side.
17. LOGGING
Audit logs for sensitive information.
Ensure logs do not unnecessarily contain:
Passwords
Session tokens
API keys
Bot tokens
Payment secrets
Authorization headers
Sensitive personal information
At the same time, preserve useful security/audit logging for admin actions.
18. DEPENDENCIES
Inspect:
package.json
package-lock / lockfile
installed dependencies
Identify known security issues where tooling available in the project can verify them.
Run the project’s existing dependency/security audit commands where appropriate.
Do NOT blindly upgrade every dependency.
If an upgrade is required, explain:
Package
Current version
Reason
Security impact
Compatibility risk
19. DATABASE / RACE CONDITIONS
Inspect sensitive operations for race conditions.
Pay particular attention to:
Orders
Inventory
Product availability
Telegram event processing
Idempotency
Payments
Admin actions
Use transactions/atomic operations where necessary.
Do not rewrite working architecture without evidence of a real issue.
20. PRODUCTION CONFIGURATION
Audit production readiness for a VPS deployment.
Check:
Environment variables
Production secrets
NODE_ENV
HTTPS assumptions
Cookies
Proxy configuration
Reverse proxy behavior
Host validation
Port exposure
Debug mode
Source maps
Public files
Database exposure
Internal services
Do not assume localhost-only services are secure if they are exposed through the network.
21. SECURITY HEADERS
Determine which headers are appropriate for this specific application.
Do not blindly copy a generic security-header configuration.
Explain each proposed header and whether it could affect:
Telegram
external images
payment providers
analytics
fonts
APIs
existing frontend functionality
22. EXISTING FUNCTIONALITY MUST NOT BREAK
This is critical.
The following MUST remain functional:
Product creation
Product editing
Product deletion
Product pages
Categories
Search
Checkout
Orders
Authentication
Admin Panel
Telegram Bot
Telegram publishing
Telegram queue
Telegram webhook
Telegram custom emoji system
Telegram product button
Product navigation
EN/AR/RU localization
Image uploads
Application navigation bar
Existing APIs
Do not perform unrelated refactoring.
23. DO NOT CLAIM “100% SECURE”
Security cannot be proven absolutely.
After the audit, classify findings as:
Critical
High
Medium
Low
Informational
For every finding provide:
Vulnerability
Exact location
Why it is vulnerable
Attack scenario
Potential impact
Recommended fix
Risk of implementing the fix
Do not label something as a vulnerability without evidence from the actual code/configuration.
24. ANALYSIS OUTPUT
Before changing anything, provide:
A. Executive security summary
B. Attack surface
C. Critical findings
D. High findings
E. Medium findings
F. Low findings
G. Informational findings
H. Authentication findings
I. Authorization findings
J. API findings
K. Database findings
L. File upload findings
M. XSS findings
N. SSRF findings
O. Telegram findings
P. Secrets findings
Q. Dependency findings
R. Production/VPS findings
S. Security headers recommendations
T. Exact files that would need modification
U. Database migrations required, if any
V. Testing strategy
W. Remediation priority
X. Final implementation plan
25. STRICT STOP CONDITION
After completing the analysis and remediation plan:
STOP.
Do not modify anything.
Do not create files.
Do not run migrations.
Do not rotate secrets.
Do not upgrade dependencies.
Do not change configuration.
Do not install packages.
Wait for my explicit approval.
After I approve, implement only the approved security fixes.
During implementation:
Make minimal changes.
Preserve existing functionality.
Avoid unrelated refactoring.
Re-read every file before modifying it.
Prefer existing utilities and libraries.
Add tests for every security fix where practical.
After implementation, run:
npx tsc --noEmit
npx next build
existing test suite
appropriate dependency/security audit commands
targeted security tests
Finally provide a complete changelog and verification report.