1 · Harden first
Objective — close the obvious doors before anything watches them: rotate every vendor default, lock down file permissions, throttle sensitive endpoints, and audit mass assignment + session cookies so the app faces real traffic with no public-knowledge secrets and no mass-assignment holes.
Background
Section titled “Background”The CodeCanyon package shipped with defaults that are public knowledge — every other buyer downloaded the same admin login, the same demo tokens, the same APP_KEY. Close the obvious doors before you wire anything that watches them. This page is the doctrine and the audit; the next page handles header/middleware code.
Rotating the secrets is half the job; how you record what the audit finds is the other half.
1. Rotate every vendor default
Section titled “1. Rotate every vendor default”Change the default admin login, regenerate the app key, and revoke any seeded API tokens the package shipped with.
-
Regenerate the app key.
Terminal window php artisan key:generate # new APP_KEY — invalidates old encrypted payloads- ✅ A fresh
APP_KEYis written to.env.
- ✅ A fresh
-
Work the rotation checklist — change the default admin login (👤, demo account deleted not just disabled), regenerate
APP_KEYon each environment, revoke seeded/demo API tokens, and purge vendor demo data from the production database.- ✅ Every default credential, token, and demo record is gone from production.
2. Rate limits + file permissions
Section titled “2. Rate limits + file permissions”Throttle auth and sensitive endpoints, and confirm secrets and backups are not web-reachable. A backup folder served over HTTP is a data breach waiting to be indexed.
-
Throttle auth — apply Laravel’s
throttlemiddleware to login, registration, password-reset, and any token-issuing route.- ✅ Sensitive auth routes carry a
throttlemiddleware.
- ✅ Sensitive auth routes carry a
-
Restrict CORS — if the app exposes API routes, set
allowed_originsinconfig/cors.phpto your own domains, never*— an open CORS policy lets any site call your API with the user’s credentials.- ✅
config/cors.phpallowed_originslists only your domains.
- ✅
-
Confirm secrets and backups 404/403 —
.env,storage/, and any backup directory must sit outside the web root or be denied by the server.Terminal window curl -s -o /dev/null -w "%{http_code}" https://<YOUR_DOMAIN>/.env# Expected: 403 or 404 — never 200curl -s -o /dev/null -w "%{http_code}" https://<YOUR_DOMAIN>/storage/# Expected: 403 or 404 — never a listing- ✅ Both commands print
403or404— no200, no directory listing.
- ✅ Both commands print
3. Audit mass assignment
Section titled “3. Audit mass assignment”$guarded = [] on a model is a mass-assignment hole — a crafted request can set columns you never exposed. Prefer explicit $fillable.
-
Scan the models for the hole.
Terminal window grep -rEn 'guarded\s*=\s*\[\s*\]' app/Models/# Expected: no matches (any result = a dangerous model to fix)grep -rn 'unguard(' app/Models/# Expected: no matches — unguard() disables mass-assignment protection globallygrep -rn 'guarded\|fillable' app/Models/# Expected: every model has an explicit $fillable list- ✅ No
$guarded = []orunguard()calls; every model declares an explicit$fillable.
- ✅ No
-
Resolve each finding against the risk table — replace any
$guarded = [](and any model defining neither) with an explicit$fillable.Finding Risk Action $fillablewith specific fieldsSafe None $guardedwith specific fieldsSafe None $guarded = []Dangerous Change to explicit $fillableNeither defined Medium Add explicit $fillable- ✅ No model uses
$guarded = []; vendor findings are tracked, not patched in place.
- ✅ No model uses
If the offending model is a vendor file, follow the tracking-issue rule above rather than editing it directly.
4. Audit session security
Section titled “4. Audit session security”Confirm production session cookies are locked down so they can’t be read by JavaScript, sent over plain HTTP, or replayed cross-site.
-
Read the current session cookie config.
Terminal window grep -E "(secure|same_site|http_only)" config/session.php# Expected: the secure / same_site / http_only lines print for review- ✅ You can see the current values for all three cookie flags.
-
Confirm each setting matches the production expectation, then set
SESSION_SECURE_COOKIE=truein the server.env.Setting Expected (production) Risk if wrong secureenv('SESSION_SECURE_COOKIE', true)Cookie sent over HTTP http_onlytrueXSS can read the session cookie same_site'lax'Cross-site request forgery - ✅
secure,http_only, andsame_site=laxall hold, andSESSION_SECURE_COOKIE=trueon the server.
- ✅
Run this audit after the rest of the security work — it’s the verify-and-track pass that catches what the earlier steps missed.
Checklist
Section titled “Checklist”Do not mark this step done until every box below is checked.
- 🔀 Every vendor default rotated — admin login (👤),
APP_KEY, demo tokens, demo data all gone. - 🤖 Endpoints + files locked — auth throttled, CORS scoped to your domains (no
*),.env/storage//backups confirmed not web-reachable. - 🤖 Mass-assignment audit done — no
$guarded = []; vendor findings tracked in_CUSTOMIZATIONS.md. - 🤖 Session cookies hardened —
secure+http_only+same_site=lax;SESSION_SECURE_COOKIE=trueon the server.