One of the most persistent vulnerabilities I find, even in 2026, is trusting user input. SQL injection and cross-site scripting (XSS) are not new threats. Yet they consistently top breach reports because developers underestimate the number of entry points in a modern application.

The rule is simple: validate shape, sanitise content, never trust origin. An input coming from your own front-end is no more trustworthy than one coming from a fuzzer. Treat them identically.

⚠️ Common mistake: Using string interpolation inside SQL queries even when the values "come from a dropdown." Dropdowns are client-side. A request can be crafted manually in milliseconds.

// Never do this
\(query = "SELECT * FROM users WHERE email = '\)email'";


// Instead, validate type before using filter_var
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    throw new InvalidArgumentException('Invalid email address.');
}

// and ALWAYS use prepared statements
\(stmt = \)pdo->prepare('SELECT * FROM users WHERE email = :email');
\(stmt->execute(['email' => \)email]);

For HTML output, never roll your own escaping. Use htmlspecialchars($value, ENT_QUOTES, 'UTF-8') or rely on your templating engine's auto-escaping. In 2026, if your template engine doesn't escape by default, replace it! That's a non-negotiable baseline.

One area teams often overlook is JSON input from REST APIs. Just because data arrives as structured JSON doesn't mean it's safe. Validate every field against a schema. Libraries like justinrainbow/json-schema make this straightforward and add almost no overhead.

2. Secure Session Management

PHP's session mechanism is powerful and, when misconfigured, a liability. Session hijacking, fixation attacks, and CSRF are all rooted in poor session hygiene. I've seen companies spend months on application features while running sessions with no expiry, no regeneration on privilege change, and cookies accessible via JavaScript.

The first thing I check in any security audit is the session cookie configuration. These should be set before session_start() is ever called:

session_set_cookie_params([
    'lifetime' => 0,          // expire on browser close
    'path'     => '/',
    'domain'   => '.yourdomain.com',
    'secure'   => true,       // HTTPS only
    'httponly' => true,       // no JS access
    'samesite' => 'Strict'    // CSRF mitigation
]);

ini_set('session.use_strict_mode', '1');
ini_set('session.use_only_cookies', '1');

session_start();

// Regenerate ID on authentication
session_regenerate_id(true); // true = delete old session

⚠️ In production right now: Rotate session IDs on every privilege change — login, role switch, password change. Not just on login. An attacker who has a valid pre-auth session ID can wait.

Implement idle timeouts in application logic, not just cookie lifetime. Store a last-activity timestamp in the session and invalidate it server-side after your threshold, typically 15 to 30 minutes for sensitive applications. PHP's native cookie lifetime is not a reliable substitute.

If you're running a distributed or containerised environment, move session storage out of the default file system and into Redis or Memcached. File-based sessions in a multi-node setup create race conditions and complicate deployment, which can become security problems at scale.

3. Dependency Management & Update Policy

Open-source libraries form the backbone of modern PHP development. They also represent one of the most common vectors for supply chain attacks. In 2026, threat actors actively target popular packages, often waiting months between poisoning a package and triggering a payload.

Composer is excellent, but it requires discipline to use securely. Most teams run composer install from a committed composer.lock and call it a day. That's a starting point, not a policy.

# Check for known vulnerabilities in installed packages
$ composer audit

# Show all outdated packages with latest versions
$ composer outdated --direct

# Validate lock file integrity before deploying
$ composer validate --strict

Wire composer audit into your CI pipeline. Every pull request should fail if it introduces a dependency with a known CVE. This is a one-line addition to any GitHub Actions or GitLab CI configuration.

💡 Policy recommendation: Define a written dependency update SLA — critical CVEs patched within 48 hours, high severity within one week, medium within the next sprint. Without a written policy, "we'll update it eventually" means never.

Keep an eye on your transitive dependencies as well. A package you trust might bring in something you've never checked. Always review the changes whenever a dependency is updated, not just the first time. Your continuous integration tools should automatically highlight these updates.

4. Authentication Hardening

Authentication is where the stakes are highest and where I still see the most avoidable mistakes. In 2026, "username and password" as a sole authentication mechanism is not acceptable for anything beyond a throwaway prototype.

Always hash passwords using a strong algorithm like bcrypt or Argon2. Never rely on MD5, SHA-1, or unsalted SHA-256. I have seen production databases this year still storing MD5-hashed passwords. This is not just a thing of the past, because it remains a real security risk.

// Hashing on registration or password change
$hash = password_hash(
    $plaintextPassword,
    PASSWORD_ARGON2ID,
    ['memory_cost' => 65536, 'time_cost' => 4, 'threads' => 3]
);

// Verification at login
if (!password_verify(\(plaintextPassword, \)storedHash)) {
    // Constant-time comparison is built-in — don't roll your own
    throw new AuthenticationException();
}

// Rehash if cost factors have changed
if (password_needs_rehash($storedHash, PASSWORD_ARGON2ID)) {
    // Update hash in database
}

Implement rate limiting on authentication endpoints. Brute-force attacks are trivially automated. A login endpoint with no throttle and no lockout policy is an open invitation. Combine rate limiting with account lockout after a defined threshold, and use exponential backoff to slow down persistent attackers.

Always enforce multi-factor authentication for any privileged access such as admin panels, API key management, and billing at a minimum. TOTP based on RFC 6238 is widely supported by libraries and authenticator applications. Passkeys using WebAuthn are becoming increasingly common in 2026 and completely remove the issue of password reuse; consider incorporating them into your next new project.

5. Secrets & Environment Hygiene

The single most preventable class of breach I've witnessed is leaked credentials. API keys committed to git, database passwords in config files checked into public repositories, private keys rotated after a breach rather than before.

Treat every secret as if it will eventually be exposed, because statistically, over the lifetime of an application, it will be. Design your system to make rotation cheap and fast.

🚨 Critical — verify this now: Run git log --all --full-history -- "*.env" on your repository. You may find secrets committed and deleted years ago that are still fully recoverable from git history.

// Pull from environment — never hardcode
$dbPassword = getenv('DB_PASSWORD')
    ?: throw new RuntimeException('DB_PASSWORD not set');
/**
 In production: inject via your platform (ECS task definition,Kubernetes secret, AWS Parameter Store, HashiCorp Vault, etc.)
Never write secrets to .env files that are committed to source control.
**/

Adopt a secrets manager like AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager are all production-grade choices. The operational overhead is lower than it was five years ago, and the protection is orders of magnitude better than dotenv files. Automate rotation using the platform's built-in rotation features so that a leaked credential has a bounded blast radius.

Scan your repositories continuously using tools like truffleHog or GitHub's secret scanning. Set up pre-commit hooks that block commits containing patterns matching API keys, connection strings, or private keys. Prevention is cheaper than remediation by a factor of one hundred.

6. Laravel-Specific Considerations

I have built production systems in Laravel for years, and it remains my framework of choice for PHP. Not because it handles security for you, but because it provides well-designed primitives that make doing things correctly the path of least resistance. That said, defaults can still be misconfigured or bypassed.

Don't Disable CSRF Protection

Laravel's VerifyCsrfToken middleware is on by default and covers all state-changing routes. The only legitimate reason to add a route to the $except array is for webhook endpoints that must accept external POST requests with a verified signature. If you find yourself excepting user-facing routes "because the form doesn't work," the form is broken, not the CSRF protection.

<form method="POST" action="/profile">
    @csrf
    @method('PUT')
    {{-- fields --}}
</form>

// For JavaScript requests, include the token header:
axios.defaults.headers.common['X-CSRF-TOKEN'] =
    document.querySelector('meta[name="csrf-token"]').content;

Policies For Authorization, Not Ad-Hoc Checks

Laravel's Gate and Policy system exists to centralise authorisation logic. Define Policies, register them in AuthServiceProvider, and use \(this->authorize() in controllers. Scattering if (\)user->role === 'admin') checks across controllers, middleware, and Blade templates is fragile — change the role string once, and you'll miss a check somewhere.

// In PostPolicy.php
public function update(User \(user, Post \)post): bool
{
    return \(user->id === \)post->user_id
        || $user->hasRole('editor');
}

// In PostController.php
public function update(Request \(request, Post \)post): Response
{
    \(this->authorize('update', \)post); // throws 403 if denied
    // ...
}

Mass Assignment Protection

Never set \(guarded = [] on a model that handles user input. Always be explicit with \)fillable. An overly permissive model combined with a form that passes request data directly to create() or update() is a privilege escalation waiting to happen.

Encryption, Hashing, and Key Rotation

Use the Hash facade for passwords and the Crypt facade (or Eloquent's encrypted cast) for sensitive fields (PII, tokens, financial data). Keep your APP_KEY in your secrets manager and rotate it with php artisan key:rotate (available since Laravel 11). Never commit it to source control.

✅ Laravel 11+ tip: The key:rotate command handles graceful re-encryption of existing data. Plan your rotation window during low-traffic periods and test on staging first.

Rate Limiting & Structured Logging

Use Laravel's built-in rate limiting on authentication and sensitive endpoints. The RateLimiter facade gives you fine-grained control beyond what the throttle: middleware offers.

RateLimiter::for('login', function (Request $request) {
    return Limit::perMinute(5)->by(
        \(request->input('email').'|'.\)request->ip()
    );
});

Log all authentication events, authorisation failures, and significant data changes using structured logging (not just plain text) so your Security Information and Event Management (SIEM) or log aggregator can parse and alert on patterns.

Final Thoughts

Security is not a feature you add at the end of a sprint — it's a property of the entire development process. The thing that separates secure teams from breached ones isn't technical knowledge. It's discipline and culture: doing the boring, repeatable things consistently.

Validate your inputs. Harden your sessions. Audit your dependencies on a schedule. Store secrets properly. Use your framework's security primitives as designed. And keep learning! The threat landscape shifts faster than any single article can capture.

The cost of getting this right is measured in hours. The cost of getting it wrong is measured in months of incident response, lost user trust, and regulatory exposure. It's not a close comparison.

Developers who openly use AI tools in their workflow often face criticism, such as:

• “You lost your touch.”

• “You are not a real/hardcore programmer anymore.”

• “AI writes your code now.”

• “You are cheating.”

These comments aren’t unique to AI. Our industry has always seen skepticism about new tools. The idea is: if a machine helps you write code, your skills must be less valuable.

According to a 2026 developer survey by Boundev, 66% of developers are concerned that AI will replace human roles. These numbers reflect how often people resist new tools.

I hold a different perspective:

Using a better tool does not erase your skill. It exposes how you apply it.

This Is Not the First Time

This pattern has always existed in software development.

When frameworks appeared, teams hesitated in their first year, worrying about code quality and losing expertise.

According to Peymaan Abedinpour, when PHP frameworks gained popularity, some developers took pride in building applications from scratch and viewed writing raw PHP as a mark of a true programmer.

But frameworks like Laravel and FastAPI changed web development. Teams could release features in days instead of weeks, and bugs in things like routing and authentication became less common because frameworks handled them well. This lets developers focus on business logic, and projects move faster with more confidence in the code.

Routing, authentication, migrations, and queues were made standard.

Some defied. Many adapted. Eventually, frameworks became the norm.

Similar doubts arose with the adoption of graphical IDEs and version control like Git. Early on, some said real programmers didn’t need visual tools or automation, and that these would erode true craftsmanship. Even the move from manual memory management to languages with garbage collection faced criticism.

Yet today, those tools define contemporary software development.

AI-assisted coding is just the next step in this evolution.

The Judgment Around AI

Many developers think vibe coding (using AI to quickly create or modify code, frequently relying on AI-generated suggestions instead of writing everything yourself) means letting AI generate code without really understanding it.

The assumptions often sound like this:

• The developer blindly copies and pastes code.

• The developer no longer understands the architecture.

• The developer stopped learning fundamentals.

• The developer produces fragile software.

Sometimes these concerns are real. Some developers do misuse AI tools like that.

But this assumption ignores how experienced engineers actually work.

Senior developers use AI thoughtfully, shifting focus to high-impact problems.

Instead of repetitive typing, they focus on work where experience matters:

• System architecture. Deciding how services communicate, how data flows, and how systems scale.

• Security. Reviewing authentication flows, validating authorization logic, and preventing vulnerabilities.

• Performance. Evaluating database queries, cache techniques, and latency.

• Maintainability. Refactoring generated code into clear and understandable modules.

AI is an assistant, not a replacement.

Typing less code does not mean thinking less.

Yes, Vibe Coding Can Be Harmful

It is necessary to be honest about this aspect.

Careless vibe coding can harm both developers and businesses.

For example:

• A developer generates a complex API endpoint and deploys it without reviewing the logic.

• A team ships AI-generated features without writing or reviewing tests.

• The authentication code is copied from the AI output without verifying the hashing methods or the token-handling logic.

• Database queries are accepted without analyzing indexes or execution plans.

In these situations, AI itself isn’t the problem.

The real issue is not the tool, but a lack of discipline.

Poor engineering practices existed long before AI appeared.

AI does not create bad engineers. It exposes them faster.

Every Tool Has Two Sides

Technology always carries both constructive and destructive potential.

A knife helps a chef prepare food efficiently. The same knife harms someone when used with harmful intent.

A car helps people travel faster and connect cities. The same car becomes dangerous when driven recklessly.

People often say tools are neutral. But AI tools pick up patterns from the data they’re trained on. If that data contains biases or errors, the AI’s output can too. Knowing these limits is key to using AI responsibly.

The result depends on the user.

AI follows the same principle.

Vibe coding itself isn’t inherently good or bad. It’s the developer’s approach and discipline that determine the outcome.

What Vibe Coding Is Actually Meant For

To me, vibe coding is meant to make development smoother. For example, according to a McKinsey report, software developers using generative AI tools can complete programming tasks up to twice as fast, demonstrating that these tools genuinely boost team efficiency. However, it’s important to recognize that productivity gains may vary depending on the nature of the task, the codebase’s complexity, and how each team integrates AI into its workflow. In some cases, reviewing, adapting, or debugging AI-generated code can take extra effort. This nuance matters to developers who esteem both speed and high standards.

Software engineering involves a lot of repetitive work. AI tools save time on these tasks, allowing developers to focus on design and problem-solving.

Some examples include:

• Generating the initial structure of an API endpoint, including request validation and response schemas.

• Creating database migrations and seed data for new features.

• Drafting unit test structures that developers later improve and extend.

• Producing boilerplate CRUD operations so developers can focus on business logic.

• Suggesting refactoring approaches for complex functions.

In this process, AI creates the first draft. The developer then reviews, verifies, and improves the code. This resembles how teams approach pull requests. The first version is rarely the final one.

AI writes the first draft. Engineers write the final system.

The Factory Analogy

Consider how modern factories operate.

Factories no longer rely entirely on manual labor. Machines carry out repetitive tasks such as assembly, packaging, and sorting. Humans supervise the system, maintain the machines, and optimize production processes.

This approach boosted productivity while keeping human expertise in the loop.

Software development is moving in a similar direction.

AI handles repetitive patterns and boilerplate structures. Developers oversee the system, evaluate the output, and ensure quality.

This change doesn’t make skilled engineers less valuable. On the contrary, it highlights the importance of careful, responsible engineers.

The Developer of the Future

As AI tools get better, the skills that make a great developer will change. Picture debugging in 2030: instead of spending hours on confusing logs, you’ll work with AI advisors that spot performance issues right away, predict problems, and suggest fixes for your situation. Developers will need to use good judgment, explain what they want clearly, and guide the AI just as much as they use their technical skills.

As a developer, these are the concrete steps that I intend to follow to prepare and build skills for the AI-driven future:

• Practice prompt engineering through experimenting with various ways of asking questions or giving instructions to AI tools. Notice how the results change, and learn to craft clear, effective prompts.

• Develop strong habits for critically reviewing AI-generated code, just as you would with a teammate’s pull request. Look for edge cases, security flaws, and performance bottlenecks.

• Take online courses or attend workshops centered on AI and machine learning fundamentals to better understand the strengths and limitations of these tools.

• Work together with peers to share tips and review each other’s AI-assisted work, building collective experience.

• Keep up to date on AI tool updates and best practices, and experiment with integrating new capabilities into your workflow.

Syntax memorization will matter less. Judgment will matter more.

The strongest developers will combine several capabilities:

• Strong fundamentals in programming, algorithms, and system design.

• Extensive understanding of performance, scalability, and database behavior.

• Awareness of security risks and safe programming practices.

• The ability to guide AI tools effectively through unambiguous instructions.

• The discipline to review and refine generated code.

Developers who rely entirely on AI without understanding the output will struggle, while those who treat AI as an assistant will move faster while maintaining quality.

AI will not replace engineers. It will reveal which engineers truly understand their craft.

Ethical Concerns

It’s not only about productivity. Incorporating AI and vibe coding into software development also brings ethical responsibilities. Developers must remain accountable for their work, including any harm, bias, or security risks resulting from AI-generated code. By communicating these responsibilities from the outset, we demonstrate our dedication to progress and the well-being of users, teams, and the community.

To put these principles into action, we can follow practical steps to uphold high ethical standards:

• Always review and test AI-generated code before it goes into production. Peer code reviews help spot hidden issues or errors that the AI may introduce.

• Consistently check for bias by evaluating both the data used to generate code and the code’s impact on different users.

• Use security tools and practices to assess AI-generated code for vulnerabilities, like unsafe authentication logic or poor data validation.

• Document decisions involving AI-generated code, including any changes you make during review, so that the reasoning behind implementation is transparent for your team.

• Stay informed on best practices and the latest guidance regarding responsible AI use.

Vibe Coding Is Not a Sin

Using AI in development does not mean a programmer loses their skills or cheats. It means adapting to better tools. Technology is constantly evolving, and developers need to keep up. Just as factories brought in machines to boost production, engineers now use AI to improve development.

The purpose of vibe coding is simple. It helps good developers become better developers.

Here are a few effective steps that helped me get started:

• Experiment with a new AI development tool and reflect on where it helps or hinders your work.

• Set up a code review process specifically for AI-generated code to encourage your team to catch errors and share best practices.

• Pick one routine task and use AI to automate it, then document what you learned for others.

• Join an online community or forum focused on responsible AI-assisted development to exchange experiences.

• Take a short workshop or online course to sharpen your prompt engineering skills.

By taking action, we can build real experience and confidence with these advancing tools, ensuring our teams make the most of AI safely and responsibly.