Web Security for Developers: The Definitive Pillar Guide (OWASP, HTTPS, Laravel, Audit)

Have you ever received a call from a client saying 'the site is down' only to discover it was hacked? We at Meteora Web have, many times. An unprotected contact form, a forgotten dependency, an expired SSL certificate. The result? Days wasted cleaning up, unhappy clients, and sometimes exposed data.

This guide is not a list of abstract recipes. It's the distillation of years of repairs, audits, and production builds. We'll cover OWASP, SQL injection, XSS, CSRF, HTTPS, authentication, dependency auditing, rate limiting, and penetration testing. Every section ends with something you can apply right now.

Let's start from a premise: an insecure site is a cost, not an asset. And fixing it costs far more than preventing it.

The real cost of a security flaw

When you manage clients' budgets, as we do with our accounting background, you understand that a vulnerability is not just a bug — it's an economic risk. Weeks of lost development, reputational damage, GDPR fines. We see it every day in Italian SMEs: security is systematically undervalued.

Concrete example: a fashion e-commerce client had a login form with no rate limiting. In one night, a bot tried 50,000 passwords. Luckily we had bcrypt hashing and account lockout after 5 attempts. If not, the cost would have been huge.

The lesson? Investing in security is not a cost — it’s insurance on your revenue.

OWASP Top 10 2025 — the map of most dangerous vulnerabilities

OWASP Top 10 is the list of the most critical web vulnerabilities, updated periodically. In 2025, Broken Access Control still ranks first, followed by Cryptographic Failures and Injection. Every developer should know it like a framework manual.

We use it as a checklist in every new project: at startup, we check authentication, authorization, input validation, and encryption. If you skip this step, you're building on sand.

How to apply it in practice

Download the OWASP guide, print it, and put it on your desk. For every endpoint in your application, ask yourself: «can this be abused?» If the answer is «I don’t know», you need to dig deeper.

SQL Injection — prevention in PHP Laravel and MySQL

SQL injection is the oldest attack and still one of the most frequent. A malicious user inserts SQL commands into an input and gains access to the database. In Laravel, Eloquent ORM and Query Builder use prepared statements, which automatically neutralize injections. But beware: if you use raw SQL, you're exposed.

// ✅ Safe: Eloquent uses prepared statements
$user = User::where('email', $request->input('email'))->first();

// ❌ Dangerous: direct concatenation
$user = DB::select("SELECT * FROM users WHERE email = '" . $request->input('email') . "'");

Golden rule: never concatenate user input into SQL queries. Always use ORM, Query Builder, or native prepared statements. If you need complex queries, use DB::raw() only on controlled data.

Useful tools: a custom ValidateInput middleware to sanitize fields, and static analysis with phpstan to spot potential vulnerabilities in code.

XSS — Cross-Site Scripting: stored, reflected, DOM

XSS allows an attacker to inject JavaScript into a page viewed by other users. It can steal cookies, tokens, or redirect to malicious sites. In Laravel, Blade's template engine automatically escapes output with {{ $var }}, but if you use {!! $var !!} you are responsible for sanitization.

// ✅ Safe: Blade escapes output
<p>{{ $userInput }}</p>

// ⚠️ Use only if you have sanitized with htmlspecialchars
<p>{!! htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8') !!}</p>

CSP (Content Security Policy) is your second line of defense. We'll see how to configure it in headers.

CSRF — protecting forms and APIs with tokens

Cross-Site Request Forgery exploits a user's active session to perform unauthorized actions. Laravel has a built-in CSRF middleware that verifies a token on every POST/PUT/DELETE request. It's active by default in Blade forms when you use @csrf.

<form method="POST" action="/update-profile">
    @csrf
    <input type="text" name="name">
    <button type="submit">Update</button>
</form>

For stateless APIs (e.g., with Sanctum or Passport), CSRF is not needed because you use bearer tokens. But be careful with CORS: configure only trusted origins.

Security Headers — CSP, HSTS, X-Frame-Options

HTTP headers are an invisible firewall. Setting them correctly drastically reduces the attack surface. Here's a basic nginx configuration:

add_header Content-Security-Policy "default-src 'self'; script-src 'self';";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";

Test it now: use Security Headers to check your site. We do it on every deploy.

HTTPS and TLS — Let's Encrypt and nginx configuration

There are no excuses anymore: with Let's Encrypt SSL certificates are free and automation with Certbot is simple. Yet we still see sites with expired certificates or TLS 1.0 enabled.

sudo certbot --nginx -d example.com -d www.example.com

After obtaining the certificate, disable obsolete protocols and configure a strong cipher suite:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;

Important: enable HSTS only after verifying everything works, otherwise you lock out users in case of issues.

Secure authentication — bcrypt, Argon2, sessions

Password hashing is a cornerstone. Always use bcrypt or Argon2. In Laravel, Hash::make() uses bcrypt by default. Never MD5, never SHA1 without a salt. We have seen databases with plaintext passwords. It's an open wound.

// Registration
$user = User::create([
    'password' => Hash::make($request->password),
]);

// Login
if (Hash::check($request->password, $user->password)) {
    // password correct
}

Session management: regenerate the session ID after login ($request->session()->regenerate()). Set an inactivity timeout and use cookies with HttpOnly, Secure, and SameSite flags.

Secure dependencies — npm audit, composer audit, CVE monitoring

A vulnerable package can bring down the entire castle. New CVEs come out every week. We have an automatic workflow: on every push, CI runs npm audit and composer audit. If critical vulnerabilities are found, the deploy is blocked.

# Check PHP dependencies
composer audit

# Check Node dependencies
npm audit

# Update everything
composer update
npm update

Recommendation: use tools like Dependabot (GitHub) or Renovate to receive automatic update PRs. Never postpone a security fix.

Rate limiting and brute force protection — practical implementation

Rate limiting is your barrier against brute force attacks and DDoS. In Laravel, you can use the built-in throttle middleware:

// In routes/api.php
Route::middleware('throttle:60,1')->group(function () {
    // 60 requests per minute
});

// For login: 5 attempts per minute
Route::post('/login', [AuthController::class, 'login'])->middleware('throttle:5,1');

Note: combine rate limiting with account lockout after N failed attempts. And log everything for auditing.

Basic penetration testing for developers

You don't need to be a professional hacker to run a basic security test. Here are the tools we use at Meteora Web:

• OWASP ZAP: interception proxy and automatic scanner.
• Burp Suite Community: for manipulating HTTP requests.
• Nikto: web server vulnerability scanner.
• WPScan: specific for WordPress.

Run a scan at least once a month. Prioritize fixes by severity: critical vulnerabilities must be fixed within 24 hours, medium within a week.

In summary — what to do now

1. Check your security headers at securityheaders.com. Configure CSP, HSTS, X-Frame-Options.
2. Renew your SSL certificates (or automate with Certbot). Disable TLS 1.0/1.1.
3. Run dependency audits: composer audit and npm audit. Update packages with known vulnerabilities immediately.
4. Verify that all forms have CSRF tokens and output is sanitized (Blade {{ }}).
5. Implement rate limiting on login, registration, and public APIs.

If you need a hand, we at Meteora Web work on these topics every day. From consulting to remediation, including full audits. Because a secure site is not an option — it’s the foundation for doing business.