Secure way to Delete a record in ASP.Net MVC

Question

I want to delete a product from my ASP.Net MVC 5 website. I want to know if adding [AntiForgeryToken] and [Authorize] is enough to secure the Delete operation?

View

 <p>Delete: @Model.Name</p>
 @using (Html.BeginForm("Delete", "ProductController", FormMethod.Post, new { ProductId = Model.ProductId }))
 {
    @Html.AntiForgeryToken()
    <button type="submit">Delete</button>
 }

Controller

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult Delete(long ProductId)
{
    /* Do I need to check if the logged in User has permission to delete the product?
    var product = ProductRepository.Get(Id);
    if (product.Creator == User.Identity.GetUserId<long>())
    {
        ProductRepository.Delete(ProductId);
    }
    */

    // or, can I avoid the trip to DB and just delete the record?        
    ProductRepository.Delete(ProductId); 
}

Scenario: A hacker registers on my website and create a valid account. Now the hacker views his own product and obviously he has an AntiForgeryToken. Can he now just change the ProductId in the browser and Post a request to delete someone else's Product?

Answer 1

Short answer. That is not enough.

Antiforgery tokens just say that the person making the original page request is the person making the update.

The base authorize attribute just verifies that the user is logged in.

What you are looking for is data security. There's an example of this on microsoft's own site.

What you've stated in your last paragraph, a hacker can sign up for an account create their own list of products and given what you show them in the url could guess legitimate other records to edit

Say you have a url

https://example.com/product/edit/13

what is preventing the user/hacker from guessing at

https://example.com/product/edit/12 or https://example.com/product/edit/14

Without security at the data level that says what records a user can or can't access/update, you run into a situation where a malicious user could see or edit all kinds of information.

This is the exact scenario that FISERV found to expose other client information

from the article

Hermansen had signed up to get email alerts any time a new transaction posted to his account, and he noticed the site assigned his alert a specific “event number.” Working on a hunch that these event numbers might be assigned sequentially and that other records might be available if requested directly, Hermansen requested the same page again but first edited the site’s code in his browser so that his event number was decremented by one digit.