Can I protect my mobile application's backend API?
Short answer
Yes. WAF does not inspect differently according to whether the sender of the request is a browser or a mobile application; the API requests of the mobile backend also go through the same signature and structural checks. The settings specific to mobile traffic are on the side of learning, the blocking response and test devices. Only Browsers, which comes checked by default in the Analysis & Learning window, does not let mobile application traffic into the analysis because it filters out clients that are not recognized as browsers; while the rules of the mobile API are being taught, the check mark is removed and Country Filter is set to cover the countries of the mobile users. The Only Browsers option of AI Learning in the Learning Methods window is off by default. So that the application receives JSON instead of HTML when it is blocked, the JSON Default Blocking Page template is selected in the Blocking Page window. The traffic of test devices is introduced with Teacher: the test version of the application sends the value in the Teacher Header field in the TR7-LEARN header; these requests are not blocked; requests that reach the blocking threshold or trigger a signature in the Monitor state are taught to the rule set in every teaching period. Verifying that the client really is the application and limiting the request rate are not in WAF: a header that the application sends can be made mandatory with Required Headers but can be imitated; a rate limit is set up in L7 DDoS & Threat Protection and with Load Balancer Conditions and actions.
Problem: Mobile Traffic Does Not Look Like Browser Traffic
The requests that the mobile application sends to the backend do not come from a web browser: the User-Agent field contains the name of the application or of the HTTP library, the requests usually have a JSON body, and the application reads the blocking response not as HTML but as JSON. WAF's checks are not affected by this difference; however, the default settings have been chosen for browser traffic:
| Default | Effect on the mobile API | Setting |
|---|---|---|
| Only Browsers checked in the Analysis & Learning window | The requests of mobile clients do not enter the analysis; the analysis does not produce rules for the mobile API | The check mark is removed in the analysis |
| Country Filter = Use Selected (Local Networks, Turkey) in the Analysis & Learning window | The requests of users in other countries do not enter the analysis | Countries are added or No Filter is selected |
| The blocking response is an HTML page, status code 418 | The application cannot parse HTML; it may not recognize 418 | JSON Default Blocking Page; if needed, Blocking Status Code |
| AI Learning Only Browsers off in the Learning Methods window | Mobile traffic enters AI Learning | No change is required |
Solution
The settings are not alternatives to one another; they are applied to the mobile API together. Prerequisite: WAF is on in the vService (How do I enable WAF protection on a vService?); if the mobile API is on a separate domain name (e.g. api.example.com), its own host group is added so that it works with a mode and rule set separate from the website (How is a Host Group added; what goes into the Virtual Host Patterns field?).
Mobile API Settings
- How it works The rule set is built from mobile traffic or from the API definition, a JSON response is returned to the blocked client, and test devices are recognized as Teacher.
- Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → the Blocking Page and Learning Methods cards · Analysis & Learning on the mode card
- Requirement Modify permission in the WAF area; for Teacher, the possibility of adding a header in the test version of the application
- vService type HTTP
Step-by-Step Configuration
If the API has an OpenAPI definition, the rules are imported (Can I generate API protection rules automatically from my OpenAPI definition?); otherwise, the traffic that the host group has collected in Learning mode is analyzed. In the analysis window (the Analysis & Learning text on the mode card), the Only Browsers check mark is removed, Country Filter is set to cover the countries of the mobile users, and Start Analyzing is clicked. The paths that come out of the analysis are reviewed; only the endpoints for which WAF rules will be created should remain in the list, and it is recommended that unknown or suspicious paths be removed from the analysis with Exclude from Analysis before applying. The remaining steps are in Method 2 of the How do I set up a positive security model for an API (allowed endpoints, methods, parameters)? page.
On the WAF Management tab, the pencil icon at the top right of the Blocking Page card in the Inspection & Blocking section is clicked (Blocking Page edit screen).
Among the ready-made templates at the top of the form, JSON Default Blocking Page is clicked and the confirmation question is confirmed. The ready-made template replaces the current blocking page settings; the defined Conditional Blocking Pages entries are also removed; if there is a conditional page, the confirmation window states the number of pages that will be removed. The source returns to manual content, the content type becomes application/json, and the body is filled with a JSON object that carries the attack information (Can I return a JSON blocking response instead of HTML for API clients?).
If the application detects blocking by a specific code, a code (e.g. 403) is selected from the Blocking Status Code list; its default value is 418. The templates do not change the status code.
Edit is clicked. The setting applies across the vService, in all host groups.
The pencil icon at the top right of the Learning Methods card in the Learning & Reporting section is clicked (Learning Methods edit screen).
The Teacher switch is turned on; the secret value that the test version will send is written in the Teacher Header field, and Teaching Frequency is selected. If the test devices connect from a fixed network, Teacher IP can also be used (IPv4 only) (What is Teacher; which sources can I define as Teacher (IP, header, cookie)?).
Edit is clicked.
The test version of the application is built so that it sends the value from step 7 in a header named TR7-LEARN in each of its requests (What should the name of the Teacher Header or cookie be (TR7-LEARN); which name is used for Conditional Learning (TR7-ANALYZE)?). Teacher teaches while the host group is in Monitor or Blocking mode; this value is not put into the released version.
If the application sends a specific header (e.g. x-app-version) in every request, it is added to the Required Headers list in the endpoint's rule with Header tab → Add Common Rule for Header, and Add is clicked (Can I define required parameters (Required Query Parameters / Required Headers / Required Form Fields)?). This check looks at the presence of the header; it does not verify the correctness of the value or the identity of the client.
On the mode card of the host group, the Edit text at the bottom right corner of the title strip is clicked, WAF Mode = Monitor Mode is selected and Edit in the form is clicked; the flows of the mobile application are monitored in Event Logs, and if there is no problem, Blocking Mode is selected the same way (When should I move from Learning to Monitor and from Monitor to Blocking?). In a cluster, the changes are sent to the peer device with the default auto-sync; if Manual Sync Mode is on, they are sent with Synchronize.
Verification
A request that will be blocked is sent and the content type of the response is checked.
Command: curl -s -i -H "User-Agent: okhttp/4.12.0" "https://api.example.com/v1/items?q=1%27%20OR%20%271%27=%271"
Content-Type: application/json; attackInfo in the bodyAfter the requests of the test version, the Teacher Tracking tab is checked (if AI Learning is also on, the name of the tab becomes AI Learning & Teacher Tracking); the Teacher Tracking view is selected and Refresh is clicked.
The false positives of the test device are listed in the next teaching periodCommon Mistakes
Putting the Teacher value into the released application
Requests that carry the Teacher identity are not blocked in any mode (a request whose scan exceeds the time limit is also passed) and they loosen the rules. If the value is put into the version of the application released to the store, anyone who examines the application can teach WAF their own traffic; the value is used only in the test version and Teacher is turned off when the teaching is finished (What is the risk of a wrongly defined Teacher?).
- Leaving the Only Browsers check mark in the analysis. The requests of mobile clients do not enter the analysis; the analysis does not produce rules for the mobile API or produces them incompletely.
- Leaving Country Filter at the default. The default is only Local Networks and Turkey; the requests of users in other countries do not enter the analysis.
- Thinking that Required Headers is authentication. The header can be imitated; WAF does not verify that the client really is the application.
- Leaving the blocking response as HTML. The application cannot parse the HTML body and shows the error to the user meaninglessly; the JSON template and a status code that the application recognizes are used.
- Expecting protection without terminating TLS on TR7. For WAF to see the HTTPS content, TLS is terminated on this vService; if the application uses certificate pinning, the certificate or key that TR7 presents is pinned (Can the WAF see the content of HTTPS traffic; what is required for that?).
How it is done in the documentation
Related questions
