LARAVEL Risk Assessment & Management 4 — Questions and Answers
Question 1: What risk does Laravel's default session driver 'file' pose in a multi-server deployment?
- Sessions stored on one server are unavailable on others, causing authentication failures and potential session hijacking via predictable paths (Correct answer)
- File sessions are faster, increasing DoS risk
- File sessions do not support encryption
- File sessions bypass CSRF verification
Correct answer: Sessions stored on one server are unavailable on others, causing authentication failures and potential session hijacking via predictable paths
File-based sessions are local to each server, so load-balanced users lose their session — and predictable file paths can be exploited if file permissions are wrong.
Question 2: How does Laravel's `can` middleware help manage authorization risk on routes?
- It throttles requests by user role
- It checks a Gate policy before allowing access, returning 403 if the user lacks permission (Correct answer)
- It encrypts route parameters automatically
- It logs all route access to a security audit trail
Correct answer: It checks a Gate policy before allowing access, returning 403 if the user lacks permission
The can middleware invokes a named Gate ability or Policy method, aborting with 403 if authorization fails before the controller runs.
Question 3: Which risk does storing Laravel queue jobs in a database driver (instead of Redis) introduce at scale?
- Jobs cannot be retried on failure
- High job volume creates database table contention, potentially impacting application performance (Correct answer)
- The database driver disables job encryption
- Database-backed queues cannot use delayed dispatch
Correct answer: High job volume creates database table contention, potentially impacting application performance
Under heavy load, frequent reads/writes to the jobs table can lock rows and starve the main application database.
Question 4: What is the risk of committing the `storage/` directory to a Git repository in a Laravel project?
- It breaks Artisan commands
- It may expose log files, user uploads, cached data, and session files containing sensitive information (Correct answer)
- It disables the queue worker
- It prevents composer from resolving dependencies
Correct answer: It may expose log files, user uploads, cached data, and session files containing sensitive information
The storage directory can contain application logs, user-uploaded files, and serialized session data — all potentially sensitive.
Question 5: A Laravel app deserializes untrusted data using PHP's unserialize(). What critical risk does this introduce?
- Performance degradation on large objects
- Remote code execution via PHP object injection attacks (Correct answer)
- Database connection pool exhaustion
- Composer autoloading conflicts
Correct answer: Remote code execution via PHP object injection attacks
PHP's unserialize() can instantiate arbitrary classes with magic methods (__destruct, __wakeup), enabling code execution if gadget chains exist.
Question 6: How does enabling `strict` mode in Laravel's database configuration reduce data integrity risk?
- It prevents all INSERT operations on production
- It enables MySQL strict SQL mode, catching data truncation and type mismatches that would silently succeed otherwise (Correct answer)
- It forces all queries through a read replica
- It adds automatic query result caching
Correct answer: It enables MySQL strict SQL mode, catching data truncation and type mismatches that would silently succeed otherwise
MySQL strict mode causes the server to reject bad data rather than coercing it silently, surfacing data integrity issues early.
Question 7: Which Laravel security risk is addressed by rotating the `APP_KEY` and what must be done after rotation?
- Rotating APP_KEY prevents SQL injection; no further action needed
- APP_KEY signs/encrypts cookies, sessions, and encrypted model fields — rotation invalidates all existing encrypted data and logged-in sessions (Correct answer)
- APP_KEY controls queue worker threads; workers must be restarted
- APP_KEY is used only for Artisan commands; routes must be cleared after rotation
Correct answer: APP_KEY signs/encrypts cookies, sessions, and encrypted model fields — rotation invalidates all existing encrypted data and logged-in sessions
The application key is used for all encryption in Laravel, so rotating it decrypts nothing previously encrypted — plan for data migration and force re-login.
LARAVEL Risk Assessment & Management 4
What risk does Laravel's default session driver 'file' pose in a multi-server deployment?