New more Secure Auto Routing

The controller filters being bypassed is the most obvious risk and the most significant.

As I stated in my post, I don't use filters explicitly, it is helpful that you have pointed out that CSRF protection is implemented with a filter. More on that below...

The problem is that developers are not strictly aware of HTTP methods of a request, which can lead to defects if an attacker accesses the site with an HTTP method that the developer does not anticipate

I believe that being unaware of HTTP methods is an individual failure -- this introduces a risk which cannot be effectively remedied with better filters. Fundamentally, developers should adhere to the policy that GET operations just retrieve information, whereas POST operations are for changing server state

@sneakyimp Don't worry. You can still use legacy auto routing as before.

I'm relieved to know that I can continue to use the 'legacy' routing method -- although I must protest that it is referred to as "legacy" -- this implies OLD and OUT OF DATE and, eventually DEPRECATED. One of the things that appealed to me most about CodeIgniter was the simplicity of code organization -- the intuitive mapping of SEO-friendly URLs directly onto controllers without the need to maintain a complicated routing table. Routing tables are nice if you need fancier routing, but I believe they can introduce an additional aspect of complexity that is not just tedious, but error-prone as well. It's also quite a big change from one minor version to another if suddenly all of your autorouted methods are broken.

The risk here is that the controller filters are bypassed.
See https://forum.codeigniter.com/showthread.php?tid=81379

Personally, I feel that relying on filters to implement access control seems like a bad idea for a couple of reasons:

1) the security risks you have pointed out arise from bypassing filters, not autorouting. You expressly state the risk arises when 'there is another route with no filters.'

This vulnerability will be created when a controller method is accessible by a way that a developer does not expect,
and there is a way to bypass a checking, e.g. there is another route with no filters.

While it is true that autorouting might introduce routes a developer does not expect, so might a routing table.

2) separating permissions and access control into separately defined filters makes it less clear what permissions are required where because these permissions would live in some entirely different location from the controller methods. I believe that enforcing permissions directly in a controller is more secure, makes it much clearer how access is controlled, and completely eliminates the confusing three-way tangle of routes/filters/controllers, etc.

As for CSRF filtering being implemented by filters, I am torn. I certainly make use of this filtering, but I'm not sure there is any problem that it only applies to POST operations? I wouldn't profess to be an expert, but I have difficulty seeing how a GET operation is at risk for CSRF? In my case, if I'm expecting an operation to be POST, I always enforce that in the controller method. On the other hand, if we should enforce CSRF for GET operations, shouldn't the CSRF functionality be improved to also include GET operations?