How “Cancel” Button deletes entire business: Discovering a CSRF and Confirmation Logic Flaw

While testing a web application's business management functionality, I discovered an interesting security issue involving a destructive action: deleting a business.

At first, the application appeared to have protection against Cross-Site Request Forgery (CSRF). The legitimate deletion request included a CSRF token.

However, during testing, I discovered that the application's behavior was not as secure as expected.

By analyzing the deletion workflow, I found that the request could reach the deletion process even when the CSRF token was removed. What made the issue even more interesting was the confirmation process.

The application displayed two options:

• Cancel
• Delete Business

But during my testing, selecting Cancel still resulted in the business being deleted.

This raised an important question:

Is a confirmation mechanism really providing security if the destructive action happens regardless of the user's choice?

In this article, I will explain the issue, the testing methodology, and the security lessons behind it.

WhoAmI

I am Ankit Rathva aka Gujarati Hacker and i am a student of MCA 2nd year, I am an ethical hacker and security researcher with a passion for finding logic, authorization, and data-integrity flaws in web applications. As a bug bounty hunter and red teamer, he combines hands-on testing, forensic analysis, and careful disclosure to help teams fix impactful issues while protecting users. He publishes clear, developer-friendly writeups and practical mitigation advice — connect to follow his work or collaborate on security research.

Connect with me: https://linkedin.com/in/ankitrathva

Understanding CSRF

Cross-Site Request Forgery (CSRF) occurs when an attacker tricks an authenticated user's browser into sending an unwanted request to a website where the user is already logged in.

Imagine the following situation:

1. A victim is logged into a website.
2. The victim visits an attacker-controlled webpage.
3. The malicious webpage sends a request to the target application.
4. The victim's browser may include their authentication cookies.
5. If the application does not properly verify the request, an unwanted action may be performed.

CSRF becomes particularly serious when the affected action is destructive, such as:

• Changing account details
• Changing an email address
• Adding users
• Modifying permissions
• Deleting data
• Deleting an account or business

The Business Deletion Functionality

While testing the application's business settings, I noticed functionality for deleting a business.

The normal deletion workflow sent a POST request to a confirmation-related endpoint.

The legitimate request included a CSRF token, which initially suggested that the application was protected against CSRF attacks.

Conceptually, the request looked like this:

POST /business/confirm_delete_business

POST /business/confirm_delete_business

The presence of a CSRF token is a good security practice.

However, an important question remains:

Does the server actually validate the token?

Simply including a token in a form does not provide protection if the backend does not properly verify it.

CSRF POC CODE

The Unexpected Confirmation Behavior

After triggering the deletion workflow, the application displayed a confirmation interface.

The user was presented with two choices:

• Cancel
• Delete Business

Normally, the expected behavior would be simple:

User ActionExpected ResultCancelNo deletionDelete BusinessBusiness is deleted

However, during testing, I observed unexpected behavior.

After selecting:

Cancel

the business was still deleted.

This indicated that the confirmation mechanism might not have been correctly controlling the destructive operation.

The application appeared to provide a confirmation choice to the user, but the server-side workflow did not properly respect that choice.

Potential Impact

If successfully exploited against an authenticated victim, this type of issue could potentially lead to unauthorized deletion of a business.

Depending on the application's functionality, the consequences could include:

• Loss of business configuration
• Loss of associated resources
• Operational disruption
• Disruption of customer-facing functionality
• Unauthorized destructive actions

The exact severity would depend on the application's environment and the amount of data or functionality affected.

Security Lessons Learned

This research highlighted several important lessons.

1. Never Trust the Presence of a CSRF Token

Seeing a CSRF token in a request does not automatically mean the application is protected.

The backend must verify that the token is:

• Present
• Valid
• Associated with the correct session
• Not expired, where applicable

2. Confirmation Must Be Enforced Server-Side

A confirmation page should not merely provide a visual interface.

The server should only perform the destructive action after receiving a valid and explicit confirmation.

Conceptually:

User requests deletion
        ↓
Server displays confirmation
        ↓
User explicitly confirms
        ↓
Server validates confirmation
        ↓
Deletion occurs

User requests deletion
        ↓
Server displays confirmation
        ↓
User explicitly confirms
        ↓
Server validates confirmation
        ↓
Deletion occurs

The destructive action should not happen before the final confirmation is validated.

3. Cancel Must Actually Cancel

A cancellation option should terminate the workflow.

The expected logic should be:

If user confirms:
    Perform deletion
If user cancels:
    Do not perform deletion

If user confirms:
    Perform deletion
If user cancels:
    Do not perform deletion

Any destructive operation occurring after a cancellation should be carefully investigated.

4. Test the Entire Workflow

Security testing should not stop after discovering a missing or bypassable security token.

It is important to test the complete flow:

• Initial request
• Server response
• Confirmation page
• Cancel action
• Confirm action
• Final application state

Sometimes the most significant vulnerability is hidden in the interaction between multiple steps.

Conclusion

This research was a reminder that security is not only about whether a protection mechanism exists.

It is about whether that mechanism is actually enforced correctly.

In this case, the application included a CSRF token in the normal request, but testing indicated that the deletion workflow could still be reached without effective validation. The unexpected confirmation behavior — where selecting Cancel still resulted in deletion — made the workflow even more concerning.

The biggest lesson is simple:

Never assume a security control works just because it appears in the interface or request. Always verify what the server actually enforces.

Security testing is often about asking one additional question:

"What happens if I change this?"

Sometimes, that question reveals much more than expected.