As part of our articles detailing the 10 most frequent web attacks (as listed in the OWASP top 10), we are going to evoke “missing function-level access controls”.

Missing function level access control

A web program uses a client-server mechanic between the browser (client) and the web server. This program can also call third-party services, such as databases or webservices. Sometimes, accesses from the browser to the server’s functions are poorly controlled, and it allows pirates to access sensitive functions.

Among the most common cases of missing control, we can find the following ones:


porte ouverte

A user can simply have access to a function he should not have access to. For instance: someone wishing to book a flight ticket usually has to go through the following steps: ticket selection -> paying -> seat selection. If the function “seat selection” is poorly configured and its access poorly controlled, a pirate will potentially be able to bypass the “paying” step, choose his seat and then completely validate his ticket without having spent a single dollar. The access to this function should have been authorized only when the previous step, “paying”, is completed; instead, its access was free.


The access to databases (name/surname/email/credit card number/etc…), such as the CRM or the ERP for instance, can happen in many ways, that are often linked to a missing access control. For more details about the used methods, discover our article: Cybersecurity, an unknown and underestimated stake.


When the authentication mechanism relies on the client, or if the type of data sent to the server is not controlled, the risk is important. Let us take the example of an “identifier/password” identification implying a Flash module that makes the dialog box more esthetic. If the code is not well thought, it is possible to find the following pattern:

  • The user enters his identifier and password
  • This information is sent by the browser to the Flash module, which will send a request to the server
  • The server sends back the whole of the “identification/password” database to the Flash module
  • The Flash module compares and controls the user’s information
  • Then validates or invalidates the connection

The Flash module is an unsecure element. When it receives the whole of the database, these elements are “clear” and thus visible by anyone without the need of major hacking competences. If this Flash/server interaction had been well thought, the Flash module would have simply sent the information to the server. The latter would have made the comparison itself, and would have sent to the Flash module an agreement or a disagreement for the connection, instead of sending the whole database.


Let us take the example of a website selling high-end televisions. Usually:

  • The user wishing to buy a 3 000€ television puts it in his basket
  • The user pays (for instance via PayPal)
  • PayPal receives the payment
  • PayPal sends back to the website a confirmation that the payment was validated
  • The website validates the order
  • The user receives a buying confirmation and will receive his product

If the access to the PayPal webservice’s function is poorly controlled so that everyone can modify some parameters, it will be possible for the pirate to replace, during the sending of the payment request to PayPal, the 3 000€ price with, for instance, 1€. Thus, the user will pay 1€, PayPal will validate the 1€ payment and will send a payment confirmation to the website in question. The problem is that the payment confirmation does not mention the value of the payment. The website will thus see no problem in validating the order, sending the television to the pirate who will have paid it only 1€. All this because the access to the PayPal webservice was poorly configured and easily accessible.


Often, numerous functions are accessible and active on the server, but their access authorization happens at the browser level. When it is the case, a pirate could access these functions by bypassing the browser filter (the function is masked on the user’s side, but it is possible to access it directly through the server, where it stays active). Let us take the example of the function “price re-indexation”. This function enables to update the whole of the catalogue’s prices, it is an action that demands a lot of time and resources. That is why e-retailers mainly use this function at night. A pirate having understood that the access filtration does not happen on the server but on the browser will be able to bypass the latter and access this re-indexation function. He will be able to control it and launch it for instance every minute, all day long, which will lead to too strong a demand for the website’s resources, which will cause the website to go down. It will not be able to function and answer to the users’ legitimate requests anymore.

Checklist with green check isolated on whiteDetect and avoid missing control problems

  1. Services offered by the website must benefit from an efficient authentication module, which will only make the function the user actually has access to appear and, especially, which will block on the server’s side what should not be accessible
  2. Filtrate the administrative functions’ access, through a control via IP and/or login and password
  3. Also filtrate additionnal components or third-party services (such as webservices) by IP and login/password
  4. Make sure that the framework and/or the website’s code are restrictive enough

CerberHost’s answers to missing function level access control

cerberhostIt is complex to treat this problem on the level of the hosting components because it is essentially linked to the design of the application and to the quality of the source code.

However, the security architects will make sure, before a production launch, that the sensitive services are already filtered through IP, in order to limit direct access to functions from outside the website. For instance, someone won’t be able to directly access a webservice if its access is limited to the IP of the web server only.

In the same way, our WAF (Web Application Firewall), NAXSI, will also be able to:

  • Detect some attack attempts put in URL parameters
  • Deduct from the activity of an IP that is is malevolent,
  • Block its accesses.

The real security thus relies on the pre-production launch audit that will put in light the potential missing filtration of accesses to sensitive functions.

Discover CerberHost

video de présentation de CerberHost

CerberHost protects your website against all Top 10 OWASP attacks, and much more.

To discover CerberHost in pictures, watch its presentation video HERE.

Lucie Saunois
Lucie Saunois
IT aficionado, specifically when it comes to cybersecurity, since she joined OT Group in 2015, Lucie specializes in making technical, and often complex, topics understandable by anyone.