DEV Community: Abdulshakoor

2 Password Reset Mistakes Developers Still Make

Abdulshakoor — Tue, 26 May 2026 10:26:36 +0000

Password reset is one of those features that looks simple until you start thinking about it from a security point of view.

The flow is usually straightforward:

A user enters their email.
They receive a reset link.
They set a new password.
They get back into their account.

From the user’s perspective, it feels like a small part of the login experience.

But from a developer’s perspective, this flow deserves a lot more attention.

Why?

Because a password reset token is not just a random string.

It is temporary access to a user’s account.

If someone gets access to that token while it is still valid, they may be able to reset the password without knowing the old one.

That is why reset tokens should never be treated like normal application data.

Exposing reset tokens without thinking about leakage

Many apps use reset links like this:

https://example.com/reset-password?token=abc123

This approach is common, but the risk starts when we forget where URLs can end up.

A reset URL can accidentally appear in:

browser history
server logs
analytics tools
error tracking tools
screenshots
third-party scripts
referrer headers

That does not always mean instant compromise, especially if the token is short-lived and single-use.

But it does increase the attack surface.

The important thing to remember is that the token in the URL is not harmless. It represents temporary account access.

Storing reset tokens in unsafe places

Another mistake is allowing reset tokens to end up in places where they should not exist.

For example:

localStorage.setItem("resetToken", token);

This is risky because reset tokens should not be stored in localStorage.

They should also not appear in:

application logs
monitoring dashboards
error reports
debugging output
frontend storage

A reset token should be handled like a temporary credential.

If you would not store a password there, you probably should not store a reset token there either.

A safer approach

A better password reset implementation usually includes these practices:

Generate a strong random token
Store only the hashed version of the token on the backend
Set a short expiry time
Expire the token after one successful use
Avoid logging reset URLs
Use HTTPS everywhere
Keep token exposure on the frontend as limited as possible

The goal is not to make the flow complicated.

The goal is to reduce the chances of a reset token being leaked, reused, or exposed unnecessarily.

Final thoughts

Password reset is not just a convenience feature.

It is part of your authentication system.

And anything that can give access to a user’s account should be handled carefully.

The main mindset shift is simple:

Do not treat reset tokens like normal data. Treat them like temporary credentials.

Small implementation details in password reset flows can make a big difference in account security.

I wrote a more detailed guide on password reset token risks and safer implementation patterns here:

https://sentrixhub.com/password-reset-tokens-in-urls-security-risks/

Password Reset Links Are Not Normal Links: A React Security Mistake Junior Developers Often Miss

Abdulshakoor — Sun, 24 May 2026 16:46:17 +0000

title: "Password Reset Links Are Not Normal Links: A React Security Mistake Junior Developers Often Miss"
published: false
description: "A beginner-friendly React security guide explaining why password reset links should be treated as temporary account access, not ordinary URLs."
tags: react, cybersecurity, webdev, beginners

canonical_url: https://sentrixhub.com/password-reset-link-risks-react-developers/

When junior React developers build a forgot-password feature, the first goal is usually simple:

Make it work.

The user enters an email.
The backend sends a reset link.
React opens the reset password page.
The user enters a new password.
The API returns success.

From a development point of view, the feature looks complete.

But from a security point of view, this is where many password reset mistakes begin.

A password reset link is not just a normal link.

It is temporary access to a user account.

If the reset token inside that link leaks before it expires, someone may be able to reset the password and take over the account.

That is why password reset link security deserves more attention, especially in React apps.

The common React password reset flow

A typical reset link may look like this:

/reset-password?token=abc123securetoken

In a React app, a developer may read that token from the URL using query parameters or React Router logic, then send it to the backend when the user submits a new password.

Technically, this works.

But the problem is that the token is now visible in the URL.

And URLs travel more than many developers realize.

A reset token in the URL can accidentally appear in:

browser history
copied links
screenshots
shared devices
server logs
analytics tools
error monitoring tools
support tickets

During local development, this may not feel dangerous because only you are testing the flow.

But in production, users open reset links from mobile email apps, office computers, shared devices, browsers with extensions, and networks you do not control.

That small frontend decision can become a real security issue.

A reset link is temporary account access

The biggest mindset shift is this:

A reset link is not just a route.

It is temporary permission to change an account password.

Many junior developers think:

“The token is random and temporary, so it is fine.”

A better security mindset is:

“The token is temporary, but while it is active, it can reset the account.”

That is why reset tokens should be:

short-lived
one-time use
validated on the backend
protected from unnecessary logging
removed from the visible URL when possible

React can help build the user interface, but the backend must enforce the security rules.

The expiration problem

Another common mistake is using long expiration times.

During development, teams often keep reset links valid for hours because it makes testing easier.

A developer sends a reset email, gets busy, comes back later, and still wants the link to work.

That is convenient for development.

But if the same setting reaches production, it increases risk.

A reset link that stays valid for several hours gives attackers more time if the link is leaked, copied, logged, or exposed through email access.

For many applications, a short expiry window such as 10 to 30 minutes is a safer starting point.

The exact expiry depends on the product and users, but the rule is simple:

If a reset link stays valid longer than the user needs, it also stays useful longer for an attacker.

What junior React developers should do instead

A safer password reset flow should include these basic protections:

Use short-lived reset tokens
Make reset tokens one-time use
Validate tokens on the backend
Avoid logging full reset URLs
Avoid storing reset tokens in localStorage
Remove the token from the visible URL after verification when possible
Use HTTPS only
Show safe and generic error messages
Test expired and reused tokens before deployment

Here is the important separation:

React should guide the user through the reset flow.

The backend should decide whether the token is valid.

The frontend can show the form.
The backend must protect the account.

A small example

A React page might read a token like this:

import { useSearchParams } from "react-router-dom";

function ResetPasswordPage() {
  const [searchParams] = useSearchParams();
  const token = searchParams.get("token");

  return <ResetPasswordForm token={token} />;
}

This pattern is common, but it should be handled carefully.

Do not log the token like this:

console.log("Reset token:", token);
console.log("Full reset URL:", window.location.href);

A safer debug approach is:

console.log("Reset token exists:", Boolean(token));

This confirms that the token exists without exposing the actual sensitive value.

The real lesson

A forgot-password feature is not only a UI feature.

It is an authentication security flow.

Junior developers should not only ask:

“Does the reset form work?”

They should also ask:

“What happens if this reset link is copied, logged, leaked, reused, or opened on a shared device?”

That one question can prevent many password reset vulnerabilities before they reach production.

Password reset security does not start with complicated tools.

It starts with treating reset links like sensitive authentication data.

This is Part 1 of a 3-part series on password reset link risks in React apps.

In Part 2, I’ll cover implementation mistakes junior developers make when they trust frontend validation too much or accidentally log reset tokens during development.

Full guide:
https://sentrixhub.com/password-reset-link-risks-react-developers/

Password Reset Tokens in URLs: Why a Simple Link Can Become an Account Takeover Risk

Abdulshakoor — Wed, 20 May 2026 18:28:43 +0000

Password reset links look simple.

A user forgets the password, enters an email address, receives a reset link, clicks it, and creates a new password.

But from a security point of view, password reset is one of the most sensitive parts of authentication security.

A typical reset link looks like this:

https://example.com/reset-password?token=abc123xyz

That token is not just a random value.

It is a temporary key to the user’s account.

If an attacker steals that token before it expires, they may be able to reset the password and take over the account.

That is why password reset should never be treated as a small convenience feature. It is part of the authentication system.

The Real Problem Is Not Only the Token

Many developers focus only on whether the reset token is random.

That is important, but it is not enough.

A token can be long, random, and hard to guess, but the reset flow can still be insecure if the application leaks that token somewhere else.

A reset token in a URL may be exposed through:

Browser history
Shared devices
Server logs
Reverse proxy logs
SIEM platforms
Third-party analytics tools
Email forwarding
Mobile app logs
Browser extensions
Referer headers

So the real question is not only:

Is the token strong?

The better question is:

Where can this token travel after the user clicks the link?

Why HTTPS Alone Is Not Enough

A common developer mistake is assuming:

“We use HTTPS, so the reset link is safe.”

HTTPS is necessary, but it does not solve every password reset risk.

HTTPS protects the token while it is moving between the browser and the server. But after the URL reaches the browser, it can still be stored, logged, forwarded, or leaked.

HTTPS does not stop:

The URL from being saved in browser history
Server logs from recording the full reset URL
Analytics tools from collecting page URLs
A user from forwarding the email
A proxy or SIEM platform from storing the URL
The browser from sending the URL in a Referer header

This is why password reset security needs layered protection.

HTTPS is required, but HTTPS alone is not enough.

A Realistic Token Leakage Scenario

One practical issue is Referer header leakage.

Here is how it can happen:

A user receives a password reset link.
The link contains a token in the URL.
The user opens the reset page.
The reset page loads a third-party analytics script, image, font, or tracking pixel.
The browser sends the full reset URL in the Referer header.
The third-party service receives the token.
If the token is still valid, an attacker may use it to reset the account password.

In this case, the attacker does not guess the token.

The application leaks it.

That is an important security lesson:

A strong token can still become dangerous if the application exposes it.

What Security Testers Usually Check

During password reset testing, security testers and bug bounty hunters usually check more than token randomness.

They check things like:

Is the token single-use?
Does the token expire quickly?
Can old tokens still work?
Is rate limiting enabled?
Are reset attempts logged safely?
Are tokens leaked in application logs?
Are tokens leaked through Referer headers?
Are third-party scripts loaded on reset pages?
Can open redirects steal the token?
Can Host header poisoning happen?
Are active sessions invalidated after reset?
Is MFA required for sensitive accounts?

A password reset bug becomes serious when it leads to account takeover.

Password Reset Poisoning

Password reset poisoning happens when an attacker tricks the application into generating a reset link with an attacker-controlled domain.

For example, if an application blindly trusts the Host header, an attacker may cause the system to generate a link like this:

text https://attacker.com/reset-password?token=real-reset-token

If the victim receives the email and clicks the link, the token may be sent to the attacker’s domain.

To prevent this, applications should:

Use a fixed trusted domain for reset links
Avoid building reset URLs from untrusted headers
Validate allowed domains
Reject suspicious Host headers
Monitor unusual reset requests

This is a small implementation detail, but it can create a serious account takeover risk.

Open Redirect Token Theft

Open redirects can also become dangerous when combined with password reset links.

Example:

text https://example.com/reset-password?token=abc123&next=https://evil.com

If the application redirects the user to the next URL without proper validation, the reset token may leak through the redirect flow or the Referer header.

Open redirects may look low-risk alone.

But when chained with password reset token leakage, they can become serious.

To reduce this risk:

Avoid open redirects
Use allowlisted redirect destinations
Never pass reset tokens to external URLs
Remove sensitive tokens before redirecting
Use strict Referrer-Policy headers

Why Reset Tokens Should Be Hashed

Reset tokens should not be stored in plaintext.

Bad example:

text user_id: 101 reset_token: abc123xyz expires_at: 2026-05-20 10:30

If the database is leaked, attackers can use those raw reset tokens directly.

A safer design is to store only a hash of the token.

Better example:

text user_id: 101 reset_token_hash: 5f2a9c... expires_at: 2026-05-20 10:30

The raw token is sent to the user.

The database stores only the hash.

When the user clicks the reset link, the backend hashes the received token and compares it with the stored hash.

This is similar to why passwords should be stored as hashes instead of plaintext.

Why Old Tokens Should Stop Working

If a user requests multiple password reset links, older links should become invalid.

Example:

User requests a reset link at 10:00.
User requests another reset link at 10:05.
The first token should no longer work.

If old tokens remain valid, an attacker may use an older email or leaked token to reset the account.

A secure system should either allow only the latest reset token to work or invalidate all previous tokens when a new reset request is created.

Why Sessions Should Be Invalidated After Password Reset

After a password reset, active sessions should usually be invalidated.

Changing the password does not always remove existing sessions.

If an attacker is already logged in, they may stay logged in even after the user resets the password.

That creates a dangerous situation:

The user thinks the account is secure, but the attacker still has an active session.

For sensitive systems, all active sessions should be revoked after password reset.

For normal applications, users should at least get a clear option to log out from all devices.

Password reset and session management should work together.

Rate Limiting Matters

Forgot password endpoints are often abused.

Without rate limiting, attackers can:

Send repeated reset emails
Test whether email addresses are registered
Abuse reset APIs
Attempt token brute force
Flood user inboxes
Automate attacks against many accounts

A secure system should rate limit:

Reset requests per email address
Reset requests per account
Reset requests per IP address
Token verification attempts
Failed reset attempts

CAPTCHA can help, but it should not be the only defense.

Attackers can use CAPTCHA-solving services, proxies, automation tools, and bot networks.

Rate limiting must be enforced on the backend.

Mobile App Deep Link Risks

Mobile apps often use deep links for password reset.

Example:

text myapp://reset-password?token=abc123xyz

or:

text https://example.com/reset-password?token=abc123xyz

Mobile reset flows can introduce additional risks:

Another app may intercept weakly configured deep links
Debug logs may store reset URLs
Crash reporting tools may capture sensitive URLs
Mobile analytics SDKs may collect screen URLs
Misconfigured universal links may open in the wrong place

Mobile apps should avoid logging sensitive URLs and should validate reset tokens only on the backend.

Practical Password Reset Security Checklist

Here is a simple checklist developers can use:

Generate strong random tokens
Keep tokens short-lived
Make tokens single-use
Store only hashed tokens
Invalidate old tokens when a new reset link is created
Avoid logging reset URLs
Avoid third-party scripts on reset pages
Use strict Referrer-Policy headers
Apply backend rate limiting
Prevent user enumeration
Validate redirect URLs
Prevent Host header poisoning
Protect mobile deep links
Invalidate active sessions after reset
Send security notifications after password change
Monitor suspicious reset activity

What Mature Security Teams Usually Do

Mature security teams treat password reset as a critical authentication flow.

They usually implement:

Short-lived tokens, often 5 to 15 minutes for sensitive systems
One-time token usage
Hashed token storage
Backend rate limiting
Device and IP anomaly checks
MFA or step-up verification for sensitive accounts
Safe logging without raw tokens
Session invalidation after reset
Security notifications
Monitoring for unusual reset behavior

The goal is not only to create a strong token.

The goal is to build a secure recovery flow around that token.

Final Thoughts

Password reset is not just a convenience feature.

It is a critical part of authentication security.

If the recovery flow is weak, attackers may not need to break the login system. They can simply abuse the password reset process.

The biggest mistake is relying only on HTTPS and assuming the reset link is safe.

A secure password reset system needs:

Short-lived tokens
One-time usage
Safe token storage
Safe logging
Rate limiting
Protection from Referer leakage
Session invalidation
Monitoring and abuse detection

A weak password reset flow can silently become the easiest path to account takeover.

Dangerous SSL Validation Mistakes Still Break HTTPS Security

Abdulshakoor — Sat, 16 May 2026 10:37:42 +0000

Many developers assume HTTPS automatically guarantees secure communication.

In reality, HTTPS security depends heavily on proper SSL/TLS certificate validation. If applications incorrectly trust malicious certificates, disable verification checks, or implement weak TLS validation logic, attackers may still intercept encrypted traffic through man-in-the-middle (MITM) attacks.

During real-world security assessments, weak SSL validation problems continue appearing in:

mobile applications
enterprise APIs
internal SaaS platforms
Java applications
corporate proxy environments
legacy enterprise systems

One of the most common patterns security teams encounter is developers temporarily disabling certificate verification during testing and forgetting to restore secure validation before production deployment.

This creates dangerous situations where applications silently trust malicious certificates while appearing to function normally.

In my latest article, I explored:

SSL stripping attacks
MITM interception workflows
insecure TrustManagers
weak hostname verification
HSTS protection
enterprise SSL inspection problems
cURL verification bypass risks
certificate pinning mistakes
public Wi-Fi interception scenarios
real-world HTTPS implementation failures

One important insight:
Most SSL validation vulnerabilities come from insecure shortcuts — not sophisticated attackers.

Read the full article here:

Dangerous SSL Validation Mistakes That Enable Traffic Interception

cybersecurity #https #tls #ssl #mitm #networksecurity #appsec #devsecops #infosec #securecoding

Dangerous SSL Validation Mistakes That Still Expose Modern Applications to Traffic Interception

Abdulshakoor — Sat, 16 May 2026 10:25:10 +0000

Dangerous SSL Validation Mistakes That Still Expose Modern Applications to Traffic Interception

Abdulshakoor — Fri, 15 May 2026 15:57:22 +0000

![Realistic cybersecurity scene showing a hacker performing a man-in-the-middle HTTPS interception attack on public Wi-Fi, with SSL certificate warnings, network traffic monitoring dashboards, and enterprise security screens in a dark professional SOC environment, ultra realistic, cinematic lighting, 4K.)

Many developers assume HTTPS automatically guarantees secure communication.

During real-world security assessments, weak SSL validation problems continue appearing in:

mobile applications
enterprise APIs
internal SaaS platforms
Java applications
corporate proxy environments
legacy enterprise systems

This creates dangerous situations where applications silently trust malicious certificates while appearing to function normally.

In my latest article, I explored:

I also covered practical enterprise observations, developer mistakes, and real operational security insights that frequently contribute to traffic interception exposure in modern environments.

Read the full article here:

Dangerous SSL Validation Mistakes That Enable Traffic Interception

cybersecurity #https #tls #ssl #mitm #networksecurity #appsec #devsecops #infosec #securecoding

Serious STP Failures That RSTP Prevents Automatically

Abdulshakoor — Fri, 08 May 2026 18:30:10 +0000

Most beginners learn Spanning Tree Protocol (STP) as a simple loop prevention mechanism.

But in real enterprise environments, STP behavior directly affects:

failover speed
VoIP stability
topology recovery
switch performance
overall network uptime

One thing many engineers notice during Layer 2 instability is that the first warning signs usually appear before users report a complete outage.

Common symptoms include:

MAC flapping warnings
temporary VoIP clipping
frequent topology changes
slow switch management response
intermittent VLAN instability

Traditional STP successfully prevents loops, but its slow convergence process can become a serious operational limitation in modern switching environments.

During uplink failures, legacy STP may spend valuable time moving ports through Listening and Learning states before traffic forwarding resumes.

In production networks, even short convergence delays can interrupt:

voice traffic
authentication systems
server communication
wireless connectivity

This is one reason Rapid Spanning Tree Protocol (RSTP) became such an important improvement.

RSTP significantly improves:

convergence speed
failover recovery
topology stability
enterprise switching resilience

One practical difference becomes obvious during link failures.

With traditional STP:

recovery may feel slow
users may notice temporary outages
applications may briefly disconnect

With properly configured RSTP:

alternate paths activate rapidly
failover becomes much faster
network disruption is minimized significantly

In many enterprise switching environments, users may not even notice an uplink failure when RSTP is configured correctly.

I recently wrote a detailed breakdown covering:

serious STP failures
RSTP failover behavior
convergence delays
root bridge instability
broadcast storm risks
practical enterprise observations

Read the full article here:

https://sentrixhub.com/serious-stp-failures-that-rstp-prevents/

networking #ccna #cisco #rstp #stp #switching #networkengineering #cybersecurity #enterprisenetworking

Dangerous STP Timer Mistakes Beginners Make in Networking (Spanning Tree Protocol Explained)

Abdulshakoor — Wed, 06 May 2026 18:06:47 +0000

Spanning Tree Protocol (STP) is a critical network protocol used to prevent Layer 2 loops in Ethernet networks. While it is highly reliable with default settings, many beginners accidentally misconfigure STP timers, leading to unstable networks and performance issues.
In this article, we will explore the most common STP timer mistakes beginners make and how these mistakes impact network stability and convergence.
⏱️ Understanding STP Timers
STP uses three main timers to control network behavior:
Hello Time – How often the root bridge sends BPDUs
Forward Delay – Time spent in listening and learning states
Max Age – Time before a BPDU is considered expired
These timers work together to ensure loop-free topology and stable convergence.
⚠️ Common STP Timer Mistakes

Reducing Timers Too Aggressively One of the most common beginner mistakes is lowering STP timers to achieve faster convergence. ❌ Problem: Causes frequent topology recalculations Leads to unstable network behavior Can create temporary switching loops
Inconsistent Timer Configuration Across Switches Another serious issue is applying different STP timer values on different switches. ❌ Problem: Mismatched BPDU processing Unpredictable root bridge selection Network instability during topology changes
Modifying Default STP Values Without Need STP is designed to operate efficiently with default timer values. ❌ Problem: No real performance gain Increased risk of misconfiguration Reduced network reliability 🔄 Impact on Network Performance Incorrect STP timer tuning can lead to: Frequent topology changes Slow or unstable convergence Temporary network outages Unnecessary port blocking events 🛡️ Best Practices for STP Timers Always use default STP settings unless required Avoid manual timer tuning in production networks Ensure consistent configuration across all switches Understand full topology before making changes 📌 Conclusion STP timer configuration is not something beginners should adjust without deep understanding. While the idea of faster convergence is appealing, incorrect changes can severely impact network stability and loop prevention mechanisms. In most enterprise environments, default STP timers provide the safest and most reliable performance.