I'm working on converting an application that uses the traditional Page Controller pattern to start using the Front Controller pattern.

One of the potential problems I'm thinking about is that with a Front Controller it could be possible for an attacker to directly call arbitrary functions.

For example, requesting a URL like http://example.org/articles/read/123 would call Articles::read( 123 ), which is expected, but an attacker could request http://articles/some_random_helper_method/123, which would call Articles::some_random_helper_method( 123 ). That method could affect the system state, or output sensitive info, etc.

Obviously things like Articles::delete( 123 ) would be behind an authentication mechanism and nonces, but there could be helper functions that are used to build the results of public pages, but should still not be allowed to be called arbitrarily.

This seems like a common problem, but I haven't been able to find any discussions on it.

One solution would be to implement a naming convention (like _private_method() to distinguish between public and private methods, and then prevent methods matching that convention from being called. That's the approach Code Ignitor uses.

That wont work for me, though, because I'm converting an existing application, and renaming all the methods would break backwards compatibility. It's also prone to human error, because it relies on the developer remembering to prefix the method if it's not public.

Another solution would be to hard-code a whitelist of public methods, but that doesn't seem very elegant.

I'm wondering if there is a canonical solution for this problem?

I'm working on converting an application that uses the traditional Page Controller pattern to start using the Front Controller pattern.

One of the potential problems I'm thinking about is that with a Front Controller it could be possible for an attacker to directly call arbitrary functions.

For example, requesting a URL like http://example.org/articles/read/123 would call Articles::read( 123 ), which is expected, but an attacker could request http://articles/some_random_helper_method/123, which would call Articles::some_random_helper_method( 123 ). That method could affect the system state, or output sensitive info, etc.

Obviously things like Articles::delete( 123 ) would be behind an authentication mechanism and nonces, but there could be helper functions that are used to build the results of public pages, but should still not be allowed to be called arbitrarily.

This seems like a common problem, but I haven't been able to find any discussions on it.

One solution would be to implement a naming convention (like _private_method() to distinguish between public and private methods, and then prevent methods matching that convention from being called. That's the approach Code Ignitor uses.

That wont work for me, though, because I'm converting an existing application, and renaming all the methods would break backwards compatibility. It's also prone to human error, because it relies on the developer remembering to prefix the method if it's not public.

Another solution would be to rely setting the visibility of methods to public or private/protected, but that could also break backwards-compatibility in my context.

Another solution would be to hard-code a whitelist of public methods, but that doesn't seem very elegant.

I'm wondering if there is a canonical solution for this problem?

I'm working on converting an application that uses the traditional Page Controller pattern to start using the Front Controller pattern.

One of the potential problems I'm thinking about is that with a Front Controller it could be possible for an attacker to directly call arbitrary functions.

For example, requesting a URL like http://example.org/articles/read/123 would call Articles::read( 123 ), which is expected, but an attacker could request http://articles/some_random_helper_method/123, which would call Articles::some_random_helper_method( 123 ). That method could affect the system state, or output sensitive info, etc.

Obviously things like Articles::delete( 123 ) would be behind an authentication mechanism and nonces, but there could be helper functions that are used to build the results of public pages, but should still not be allowed to be called arbitrarily.

This seems like a common problem, but I haven't been able to find any discussions on it.

One weak solution would be to implement a naming convention to distinguish between public and private methods, but that just adds a bit of obscurity and is prone to human-error.

Another solution would be to hard-code a whitelist of public methods, but that doesn't seem very elegant.

I'm wondering if there is a canonical solution for this problem?

I'm working on converting an application that uses the traditional Page Controller pattern to start using the Front Controller pattern.

One of the potential problems I'm thinking about is that with a Front Controller it could be possible for an attacker to directly call arbitrary functions.

For example, requesting a URL like http://example.org/articles/read/123 would call Articles::read( 123 ), which is expected, but an attacker could request http://articles/some_random_helper_method/123, which would call Articles::some_random_helper_method( 123 ). That method could affect the system state, or output sensitive info, etc.

Obviously things like Articles::delete( 123 ) would be behind an authentication mechanism and nonces, but there could be helper functions that are used to build the results of public pages, but should still not be allowed to be called arbitrarily.

This seems like a common problem, but I haven't been able to find any discussions on it.

One solution would be to implement a naming convention (like _private_method() to distinguish between public and private methods, and then prevent methods matching that convention from being called. That's the approach Code Ignitor uses.

That wont work for me, though, because I'm converting an existing application, and renaming all the methods would break backwards compatibility. It's also prone to human error, because it relies on the developer remembering to prefix the method if it's not public.

Another solution would be to hard-code a whitelist of public methods, but that doesn't seem very elegant.

I'm wondering if there is a canonical solution for this problem?