Blog

Securing RESTFul endpoints with ColdBox 4

Luis Majano February 03, 2015

Spread the word

Luis Majano

February 03, 2015

Spread the word


Share your thoughts

ColdBox has sported RESTFul capabilities since the 3.0.0 days (that's since 2011).  As each release matures, our RESTFul suite of tools mature as well.  In our latest release we introduced a great way to intercept when RESTFul endpoints are called with invalid HTTP methods.  Every ColdBox handler has the this.allowedMethods structure which can tell the framework what actions can be executed with what HTTP methods.


this.allowedMethods = {
  index = "GET",
  save = "PUT,POST",
  remove = "DELETE"
}

The security map above tells the framework what HTTP methods you can use for which action. For example, the remove() action can only be executed with the DELETE HTTP method. If you execute the action with any other HTTP method, then the framework will throw a security exception. In previous version, you had to do hoops in order to intercept and gracefully show users a nice message. With ColdBox 4 we introduce the onInvalidHTTPMethod() action.

Tip: By default, every event handler controller action can be executed using ANY HTTP method.

You can place this action in the same handler or a base handler and it will become alive as soon as an action is executed with an invalid HTTP method. The signature for the method is:

 


function onInvalidHTTPMethod( faultAction, event, rc, prc ){
    event.renderData( 
       type="json", 
       data={ "error" : true, "message" : "The endpoint you called cannot be executed using the #event.getHTTPMethod()# HTTP method." } 
    ).setHTTPHeader( statusCode="405", statusMessage="Invalid HTTP Method #event.getHTTPMethod()#" );
}

The faultAction tells you what action was invalidly called and you can use the event.getHTTPMethod() to retrieve the offending method. This way you can make sure you can uniformly respond to RESTFul requests that are invalid.

Add Your Comment

Recent Entries

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

The MatchBox open beta is live at https://boxlang.ortusbooks.com/boxlang-framework/matchbox, and it brings something genuinely new to the BoxLang ecosystem: a path into WebAssembly.

That means BoxLang code can now move into browser applications, static-site deployments, edge runtimes, and WASI-style containers - without requiring a JVM. The feature is still beta, but the core direction is already useful: write BoxLang, compile it with MatchBox, and ship the generated WASM artifact to wherever a small portable runtime makes sense.

Jacob Beers
Jacob Beers
June 04, 2026
One Language, Every Runtime: BoxLang Expands Beyond the Server

One Language, Every Runtime: BoxLang Expands Beyond the Server

Discover how BoxLang’s multi-runtime architecture helps developers build beyond the server with support for serverless functions, desktop applications, CI/CD workflows, Java integrations, containers, runtime management, and more.

Maria Jose Herrera
Maria Jose Herrera
June 04, 2026
BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 ships something that JVM developers have wanted for a long time: a true first-class Set type baked directly into the language. Not a wrapper you reach for manually, not a createObject( "java", "java.util.HashSet" ) incantation you paste from a Stack Overflow answer years ago. A real BoxSet with literal syntax, operator overloads, a full functional pipeline, change listeners, JSON serialization, and deep Java interop.

Luis Majano
Luis Majano
June 03, 2026