Learn about why APIs need different testing than web apps, OWASP API Security Top 10, BOLA, BFLA, JWT authentication, GraphQL vs REST testing, and much more, through the Frequently Asked Questions (FAQs) below. Please schedule a consultation if you are looking for Penetration Testing for compliance or regulatory requirements or to comply with a global security standard..
Table of Contents
Why does API penetration testing require different techniques than web app testing?
API penetration testing requires different techniques than traditional web application testing because APIs operate on different protocols, expose different interfaces, and are consumed programmatically rather than through a browser, making them invisible to the crawlers and proxies that rely on HTML rendering to discover content.
APIs typically use JSON or XML payloads, HTTP methods (GET, POST, PUT, PATCH, DELETE), and authentication mechanisms such as OAuth 2.0, API keys, and JSON Web Tokens (JWTs) rather than the form-based authentication and cookie-based sessions common in web applications. API-specific vulnerabilities, documented in the OWASP API Security Top 10 (2023), include Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, and Server-Side Request Forgery. Testing APIs requires specialized tools (Postman, Insomnia, Burp Suite with API-specific extensions), manual examination of API documentation (Swagger/OpenAPI specifications), and techniques for discovering undocumented or hidden API endpoints that may not be linked from the application’s UI.
What is BOLA (Broken Object Level Authorization) and why is it a critical API risk?
BOLA (Broken Object Level Authorization), listed as the number one risk in the OWASP API Security Top 10 (2023), is a vulnerability in which an API fails to properly verify that a requesting user has authorization to access or modify a specific object, allowing attackers to access other users’ data by manipulating object identifiers in API requests. BOLA is the API-specific analog to IDOR (Insecure Direct Object Reference) in web applications and is considered the most prevalent and impactful API vulnerability because modern APIs return and accept object identifiers, user IDs, order numbers, document IDs, account references, in virtually every request. An attacker exploiting BOLA in a healthcare API, for example, could access other patients’ medical records simply by incrementing a patient ID parameter. BOLA is difficult to detect with automated scanning because each vulnerable endpoint looks like a valid, authorized request, the authorization failure is in the server’s logic, not in the request format. Effective BOLA testing requires creating multiple test accounts and systematically attempting cross-account access for every object-referencing API endpoint.
What is BFLA (Broken Function Level Authorization) in API security?
BFLA (Broken Function Level Authorization) is an API security vulnerability, ranked in the OWASP API Security Top 10 (2023), in which an API fails to properly enforce access controls at the function or endpoint level, allowing lower-privileged users to call API functions that should be restricted to higher-privileged roles such as administrators. While BOLA involves accessing another user’s data (unauthorized horizontal access to objects), BFLA involves accessing administrative or privileged functions that should not be available to a standard user (unauthorized vertical access to functionality). For example, a standard user API account that can call an /admin/delete-user endpoint due to missing function-level authorization checks is a BFLA vulnerability. BFLA is commonly found in APIs that expose administrative functionality in the same API surface as user-facing functionality, relying on client-side restrictions (hiding admin buttons in the UI) rather than enforcing server-side authorization checks on each request. Penetration testers identify BFLA by testing all discovered API endpoints with standard user credentials, looking for unauthorized access to administrative or elevated functions.
How are GraphQL APIs tested differently than REST APIs?
GraphQL APIs require a fundamentally different testing approach than REST APIs because of the architectural differences between the two technologies. REST APIs expose a fixed set of endpoints with predetermined request and response structures; GraphQL exposes a single endpoint that accepts flexible, client-defined queries. This creates unique security testing considerations: GraphQL introspection queries (if enabled in production) allow attackers to enumerate the entire API schema, all types, fields, and operations, providing a complete map of the API surface. GraphQL’s flexible query structure enables batching attacks, where an attacker submits multiple operations in a single request to bypass rate limiting, and deep query attacks, where deeply nested queries consume excessive server resources (a denial-of-service risk). Penetration testers examine GraphQL APIs for introspection exposure, missing field-level authorization (where a user can query fields they should not have access to), injection vulnerabilities in custom resolvers, and insufficient rate limiting. Tools such as InQL, Clairvoyance, and GraphQL Voyager are specifically designed for GraphQL security testing.
Explore Blogs, Webinars and other Resources
Trusted by Reputed Companies
Accreditations and Associations
* Disclaimer: This list of accreditations is held by our team of employees and consultants.
What Our Clients Say
We used databrackets (formerly EHR 2.0) in our small medical practice for our risk analysis assessment to be in compliance with meaningful use. Their response was fast, the final report is detailed but simple and easy to follow. They were always available to answer our questions.
E. Compres
Pulmonary and Sleep Center of the Valley
I never miss the opportunity to learn something new …that’s why I am always registering to all free seminars offered on the web. databrackets (formerly EHR 2.0) happened to be the friendliest, comprehensive and up-to- date source of HIPAA Privacy and Security updates.
Alexandra V.
Community Healthcare Network
Today’s presentation was great! Thank you for sending the slides. My only feedback is that it would be fabulous to have the slides ahead of time so I could print them and take notes on the slides.Thanks for your time and knowledge today!
T.B., PM
Community Health Network
Particularly interesting was the flow chart on Administrative Simplification. I utilize all of the Security subcategories you list under the Security tile and appreciate knowing that I am hitting all of the relevant topics during my employee training.
Jessica B.
JD, CHC
I have re-worked our original risk assessment….We are using databrackets' (formerly EHR 2.0) Meaningful Use Security Risk Analysis Toolkit and it meets our needs. It was easy to use and I believe that it very beneficial to our meeting meaningful use.
Bill Curtis
Neurosurgical Associates Of Texarkana, TX
Information (webinars) presented by databrackets (formerly EHR 2.0) highlights some of today’s most demanding healthcare topics. The webinars help to direct those operating in today’s rapidly changing environment in the right direction.
Candace M.
Privacy and Security Officer, Springhill Medical Center
Our Growing List of Credentials
0
+
Assessments
0
+
Clients
0
+
Assessment Libraries
0
+
Years of Experience
0
+
No. of Staff Trained
0
+
HIPAA
0
+
SOC 2 Readiness
0
+
Pen Testing
0
+
ISO 27001 Certifications
0
+
Dollars Saved in Compliance Penalties