MVC [HttpGet] controller annotation optional?

Question

If I have 2 controller actions:

    [HttpGet]
    public ActionResult Login()
    {
        //...

        return View();
    }

and

    [HttpPost]
    public ActionResult Login(FormCollection values)
    {
        //...

        return RedirectToAction("Index","Home");
    }

It seems that the Post decoration is required for this to work (which makes sense), but the HttpGet decoration is entirely optional. It works fine with or without. It seems that MVC defaults controller actions to HttpGet unless otherwise specified.

I'll have to decided if I want a future reader of my code to have to figure that out on my own or not, or whether I want to have to remember to add HttpGet everywhere for consistency. But my question is not about whether it is a good practice to include the explicit decoration even though it is defaulted that way already.

My question is: is it ALWAYS the case that I don't need to decorate controller methods with HttpGet? Is there some way that this can bite me if I do or do not explicitly specify? I've searched on this a but and all I can find is posts describing why you might want to use both annotations rather than the reason for/against including the HttpGet specifically.

Cordwainer

Answer 1

You don't have to specify this explicitly, no. However, please note:

• Not specifying the verb on an action will mean that the method accepts both GET and POST. If there are two actions, however, the one labelled POST will be used for POST and the other will default for GETs.
• Applying HttpGet will mean an action accepts only GET requests.
• Labelling actions as GET can make it more obvious to other developers what your intention is.

Is there some way that this can bite me if I do or do not explicitly specify?

Not very likely. I could imagine a situation where something might be showing some strange behaviour or not working as expected because of it, but it'd be rare.

Louisiana

For example you may get said strange behaviour if you implement a custom ActionMethodSelectorAttribute yourself on an ActionMethod implicitly marked as HttpGet. If this custom Attribute returns true, but it's actually a POST Request, you get an ambiguity. – Mutz

I've gotten errors thrown because a bot is trying to return the HEAD of the Action but can't because I specify it as a GET Action. Just something to keep in mind for error logging. – Myxomatosis

Answer 2

Is there some way that this can bite me if I do or do not explicitly specify?

Here I want to develop an answer of Rowan Freeman about the consequences of not using [HttpGet] explicitly for every GET method.

As it was already mentioned, a method without [HttpGet] annotation will accept both GET and POST request (unless there is another method with same name that is annotated with [HttpPost]). If a method is explicitly annotated with [HttpGet], 405 Method Not Allowed will be returned.

One consequence that I could imagine is that if an attacker wanted to send big amount of data through GET request, it would have a limit. Without [HttpGet] annotation, this limit is not a problem, because an attacker can switch to POST and do the same without any limit.

Another similar case is that:

HTTPGet can carry only string data whereas HTTPPost can carry both string and binary data.

Yet another thing is that POST requests will probably not entirely be logged on a server, therefore an attacker can somehow hide it's activity from an administrator as attackers payloads won't be visible (body won't be present in logs).

A comparison between POST and GET (which I cited from) can be found here: ASP.NET MVC 5 – HTTPGET And HTTPPOST Method With Example

Of course, all of these cases are pretty rare, but this is what exploiting is about - finding rare things that can turn out to be a vulnerability.

To conclude, it is a good habit to always write [HttpGet] annotation in controller methods. It is just a one line that can improve security of your web application.

Philharmonic