Top 10 API Security Risks

Why API Security Risks Demand Board-Level Attention

In today’s hyper-connected digital economy, APIs have quietly evolved from technical conveniences into the very lifelines of modern enterprises. Yet, as organizations accelerate their API-first strategies, many leadership teams fail to recognize that these APIs are now among the most lucrative and least defended targets for sophisticated threat actors. API security can no longer be relegated to backend discussions—it must occupy a permanent seat at the boardroom table.

APIs: The New Business Critical Infrastructure

APIs are not just code; they are the connective tissue for business operations, customer interactions, financial transactions, and intellectual property flows. An insecure API directly threatens brand reputation, regulatory compliance, and shareholder value. Unlike traditional perimeter breaches, API attacks often exploit trusted connections, making detection slower and the consequences more severe.

Attackers Exploit the Trust Model of APIs

What makes APIs uniquely dangerous is the implicit trust they represent. APIs are designed to share data, automate processes, and delegate authority—all of which attackers can exploit if proper controls are not in place. This trust-centric model means a single compromised API can cascade into a multi-system compromise, something a firewall breach or a stolen laptop rarely achieves.

API Risks Are Business Risks

The financial implications of API breaches are staggering. Gartner predicts that by 2025, more than 50% of data theft incidents will be traced back to unsecured APIs. The legal, regulatory, and operational blowback from such incidents can overnight erode years of market positioning. For CISOs and CFOs, treating API risk as a pure IT problem is an existential mistake.

Why Leadership Must Act Now

Security leaders must educate their boards that API security is not a future issue but a current battlefield. Organizations that treat APIs as strategic assets and defend them accordingly will thrive in a volatile digital era. Those who delay will find themselves not just vulnerable but irrelevant.

Broken Object Level Authorization (BOLA)

Broken Object-Level Authorization (BOLA) continues to rank as the top API security risk, not because it is technically complex but because it exploits a simple oversight: trusting users too much with identifiers. Understanding and addressing BOLA is not just about technical precision but fundamentally rethinking how your API ecosystem manages access to sensitive data.

Why BOLA Remains the Silent Killer of API Security

At its core, BOLA happens when an API grants access to objects, such as user profiles, invoices, or device records, based solely on user-supplied identifiers without verifying ownership. Attackers exploit this by manipulating object IDs to gain unauthorized access. Unlike brute-force intrusions that trigger alarms, BOLA attacks often go undetected because they mimic legitimate API calls, making them exceptionally difficult to detect in real-time.

Real-World Impact: BOLA Breaches That Changed Corporate Futures

Several high-profile API breaches, including incidents in the financial and healthcare sectors, were directly linked to BOLA vulnerabilities. In these cases, attackers accessed millions of sensitive records simply by enumerating object identifiers. What’s striking is that these breaches weren’t the result of advanced exploits—they succeeded because basic access control validation was missing at the object level.

Why Traditional Security Controls Fail Against BOLA

Firewalls, API gateways, and WAFs (Web Application Firewalls) often struggle to detect BOLA attacks because they occur post-authentication. Many systems stop scrutinizing subsequent object-level requests once a token or session is validated. This architectural blind spot means uAPIs will remain vulnerable unless developers embed authorization checks deeply into business logic.

Mitigating BOLA with a Defense-in-Depth Strategy

Preventing BOLA requires more than input validation; it demands rigorous authorization checks at every point of object access. Security leaders must enforce policies that verify whether API endpoints are entitled to the requested object, regardless of the authentication token’s validity. Role-based access control (RBAC) and attribute-based access control (ABAC) are crucial but must be integrated at the design level, not bolted on after deployment.

Moving Beyond Detection to Design

Effectively addressing BOLA means shifting the API security left and embedding access control into the earliest stages of the development lifecycle. Security teams must collaborate directly with development teams to perform threat modeling, implement consistent authorization frameworks, and automate tests that specifically validate object-level access controls.

Broken Authentication

Broken authentication remains a critical and often underestimated risk in the API landscape. It’s not just about stolen credentials or weak passwords; it’s about systemic design flaws that silently compromise the integrity of entire ecosystems. In an environment where APIs authenticate millions of transactions daily, even minor lapses in authentication controls can have catastrophic consequences.

The Subtle Complexity of API Authentication

Authentication for APIs is inherently more complex than traditional web applications. APIs often serve many consumers—mobile apps, IoT devices, third-party integrations—each requiring different authentication flows. This diversity usually leads developers to implement fragmented authentication methods, leaving behind inconsistent logic and subtle gaps that attackers eagerly exploit.

Real-World Failures: When APIs Trust Too Easily

Several breaches have exposed how even “secured” APIs trust session tokens or OAuth flows too readily without robust validation. In some cases, APIs accepted expired tokens; in others, APIs failed to verify the origin or audience fields of the token properly. Attackers leveraged these oversights to impersonate users or escalate privileges, without triggering traditional security alarms.

Why Traditional Defenses Falter

While many organizations implement multi-factor authentication (MFA) or OAuth 2 protocols, they often overlook the nuances of token lifecycle management, revocation mechanisms, and session fixation risks. Security controls that focus only on login points miss broader threats, such as stolen tokens being replayed across multiple APIs or trust being placed in weak bearer tokens issued by compromised identity providers.

Building Resilient Authentication at the API Level

Securing API authentication demands treating tokens as sensitive assets, equivalent to passwords. This includes enforcing strict token expiration times, rotating credentials frequently, validating all claims in access tokens, and binding tokens to specific clients or device fingerprints where feasible. Mutual TLS (mTLS) and signed tokens (e.g., JWTs with strong encryption algorithms) add critical layers of defense.

From Reactive to Proactive: Authentication as a First-Class Citizen

Organizations must move beyond reactive approaches to authentication breaches. Proactively embedding strong authentication controls into the API lifecycle—from design to deployment—prevents weak entry points from ever reaching production. Threat modeling sessions should explicitly consider token abuse scenarios, and security teams must rigorously test authentication flows using adversarial techniques, in addition to functional testing.

Excessive Data Exposure

Excessive data exposure is a technical misstep and a strategic vulnerability that quietly amplifies organizational risk with every overlooked API call. When APIs disclose more information than necessary—even inadvertently—they hand attackers the raw material needed for sophisticated breaches, reputation damage, and regulatory penalties.

The Quiet Threat: How APIs Leak More Than Expected

Unlike web applications, where UI-driven access can naturally limit what a user sees, APIs often serve as back-end engines exposing full objects or datasets. Developers sometimes assume clients will filter the data appropriately, but attackers see this as an opportunity. APIs that expose hidden fields, sensitive metadata, or verbose error messages empower adversaries to construct detailed intelligence maps about the system and its users.

Common Pitfalls Leading to Overexposure

Overexposure typically results from hurried development cycles, a lack of secure-by-design principles, and an over-trusting internal audience. Features such as verbose JSON outputs, broad object returns, or exposing backend system details during debugging are often left active in production environments. Even well-meaning practices, such as extensive API documentation, can unintentionally guide attackers toward rich data troves.

Why Filtering at the Client Side is a Fatal Flaw

Relying on client-side data filtering creates an illusion of security. Once data leaves the server, control is lost. Attackers often disregard front-end constraints, instead crafting direct API calls to retrieve all available information. The server must act as the final gatekeeper, ensuring that each API response delivers only the minimum necessary data, tailored precisely to the requester’s role and context.

Best Practices: Data Minimization by Default

Organizations must adopt a data minimization philosophy at the API level. This involves designing endpoints that return only essential fields, utilizing schema enforcement tools, and tightly integrating authorization checks with data retrieval logic. Techniques such as response allowlisting, API versioning with restricted fields, and dynamic data masking for unauthorized requests are essential to defend against overexposure.

Data Exposure in the Age of Machine Learning

As APIs increasingly feed machine learning models and analytics engines, the stakes of excessive data exposure grow exponentially. Leakage of training data, model parameters, or proprietary algorithms through improperly secured APIs could erode competitive advantages and violate intellectual property protections—an often-overlooked dimension of modern API security.

Lack of Resources and Rate Limiting

The absence of robust resource and rate-limiting controls is a silent invitation to attackers, allowing them to overload systems, exploit APIs for data scraping, or execute brute-force attacks without triggering alarms. Many organizations underestimate the strategic role of resource and rate controls, seeing them as performance enhancers rather than essential security defenses.

The Hidden Dangers of Unlimited Access

Without rate limiting, APIs become vulnerable to abuse at both the application and infrastructure levels. Attackers can orchestrate denial-of-service (DoS) campaigns, drain system resources, or systematically probe endpoints without resistance. Even benign errors, such as poorly optimized client applications, can unintentionally overload APIs, degrading service quality and availability.

APIs as a Gateway to Amplified Threats

Modern attackers exploit unsecured APIs to steal data and weaponize the API as a force multiplier. Without resource throttling, a compromised credential can open the floodgates to mass data exfiltration, bot-driven attacks, and pivoting deeper into backend systems. APIs without throttling controls effectively hand adversaries the keys to accelerate their operations undetected.

Common Gaps in Resource Protection Strategies

Too often, organizations implement simplistic rate limiting (e.g., per IP address) without considering session-based abuse, device fingerprinting, or geographic-based throttling. They also overlook the need for adaptive limits, recognizing changing risk profiles, such as unusual request bursts outside regular business hours. Static rules fail to keep pace with dynamic, multi-vector attack patterns.

Smart Rate Limiting: Not Just About Numbers

Effective rate limiting is not a blunt-force traffic cap; it is a nuanced approach that balances traffic control with user experience. It’s about intelligent risk management: dynamically adjusting thresholds based on user roles, behavior patterns, and risk scores. Integrating rate limiting into API gateways with anomaly detection and behavioral baselining transforms it from a performance tool into a strategic security shield.

Resource Limiting Beyond Just API Calls

Organizations should also think bigger than API call volumes. Limiting the size of incoming payloads, restricting query complexity (e.g., GraphQL depth limits), and capping file upload sizes are critical dimensions of holistic resource protection. Attackers often exploit overlooked resources, such as database processing time or memory allocations, long before they reach maximum request rates.

Broken Function Level Authorization

Broken Function-Level Authorization (BFLA) remains an overlooked but critical API security risk. Attackers exploit the absence of rigorous permission checks to access restricted functions. While many organizations focus on object-level security, they often miss function-level vulnerabilities that silently expose sensitive operations to unauthorized users.

The Often-Ignored Layers of API Permissions

BFLA happens when APIs incorrectly assume that users will only interact with functions presented through the UI or business logic layers. In reality, APIs operate independently of user interfaces, making it dangerous for attackers to craft malicious calls that invoke hidden or restricted operations without proper authorization.

Why Role-Based Access Control (RBAC) Is Not Enough

Many API developers incorrectly rely solely on Role-Based Access Control (RBAC) to protect sensitive functions. However, without context-aware and function-specific permission checks, attackers who escalate privileges or guess function names can perform critical actions, such as altering user roles, executing admin commands, or bypassing business rules entirely.

Real-World Impact: More Than Just Unauthorized Data Access

Broken Function Level Authorization doesn’t just risk data leaks; it enables direct manipulation of system settings, user privileges, and operational workflows. For example, attackers could exploit exposed API endpoints to promote themselves to administrators, disable security controls, or trigger large-scale data purges—all without proper enforcement.

The Illusion of “Hidden” API Functions

Security through obscurity is a false defense. Not documenting an API function or hiding it from standard clients doesn’t prevent attackers from discovering and abusing it. API introspection techniques, automated endpoint discovery tools, and fuzzing can rapidly expose “hidden” functionalities to determined adversaries.

Building Function-Level Authorization as a Design Principle

Protecting API functions demands a layered, default-deny approach: every function must enforce access control independently of the UI and regardless of assumptions about user behavior. Fine-grained authorization checks, token scopes, and permissions-based API design must be built into the architecture from the start, not retrofitted after an incident.

Automating Function Access Audits for Sustainable Security

Given the complexity of modern APIs, manual audits are not scalable. Automated testing frameworks that simulate API abuse scenarios and continuous authorization testing within the CI/CD pipeline provide a sustainable approach to detecting and mitigating BFLA risks before APIs are deployed to production environments.

Mass Assignment

Mass Assignment vulnerabilities are among the least understood yet most damaging threats in API ecosystems. When APIs automatically bind user input to application objects without strict filtering, attackers can exploit this trust to manipulate protected fields, bypass business logic, or escalate privileges without breaching traditional perimeter defenses.

The Silent Danger Behind Automatic Data Binding

Many frameworks offer convenience features, such as automatically binding JSON payloads directly to backend objects. While this accelerates development, it also allows attackers to supply unexpected fields, such as isAdmin: true or accountStatus: ‘active, ‘ that modify sensitive attributes developers never intended to expose.

Why “Allowing” Beats “Blocklisting” Every Time

Relying on blocklists—explicitly blocking known dangerous fields—is a losing strategy in Mass Assignment defense. Attackers only need to find one overlooked parameter. Instead, developers must enforce strict allow listing: only allow explicitly permitted fields to be set through API calls, ignoring or rejecting all others by default.

Real-World Fallout: Silent Privilege Escalations and Data Integrity Attacks

Mass Assignment vulnerabilities often don’t trigger alarms or obvious errors. Instead, they quietly allow attackers to alter records, modify account types, or access restricted services. The result can be large-scale privilege escalations, fraudulent activities, or systemic data corruption—all hidden beneath legitimate API transactions.

Why Schema Validation Alone Is Not Enough

While JSON schema validation tools are crucial, they often focus on structure rather than intent. An attacker can still manipulate allowable fields unless the API implements business logic that explicitly validates what should and should not be writable by the user, independent of format correctness.

Defensive Design Patterns Against Mass Assignment

The best defense integrates Explicit Field Mapping, Immutable Object Design, and Secure Deserialization. APIs should manually map incoming data to backend models, maintain immutability for critical fields post-creation, and validate deserialized objects before applying any business logic or storage actions.

The Strategic Role of Mass Assignment Penetration Testing

Automated scanning tools typically miss Mass Assignment risks. Organizations must perform focused penetration tests simulating malicious field injections, particularly against onboarding, profile management, and administrative endpoints, where sensitive object attributes are most often exposed.

Security Misconfiguration

Security misconfiguration remains one of the most persistent and underestimated risks in API deployment. Often viewed as a “deployment-time” problem, it is a systemic issue rooted in fragmented responsibilities, invisible complexity, and evolving ecosystems. APIs amplify the impacts of misconfiguration because they often expose backend systems directly to the internet with minimal abstraction layers.

The Complexity Problem: APIs Expose What Applications Hide

Unlike traditional applications that present tightly controlled user interfaces, APIs expose the underlying logic and structure of a system. This exposure means any overlooked configuration—be it verbose error messages, permissive CORS policies, open ports, or unencrypted endpoints—becomes an attacker’s blueprint for exploitation.

Shadow Settings: The Risk Lurking in Default and Forgotten Configurations

Default settings in API gateways, load balancers, cloud services, and container platforms are often over-trusted. Many security teams assume infrastructure templates are safe “out of the box,” but APIs layered on top inherit all the insecure defaults. Forgotten routes, deprecated endpoints, and test APIs left exposed become low-hanging fruit for attackers probing the surface.

Misconfiguration as a Breach Multiplier

While a single vulnerable API might seem like a localized risk, misconfigurations often serve as the breach multiplier. An insecure API can provide lateral movement paths, credential leaks, or application fingerprinting information, dramatically expanding the scope of an initial foothold.

Hardened Deployment Pipelines: Beyond “Scan and Fix”

Actual API security demands hardened deployment pipelines where configuration checks are integrated from code to the cloud. Before APIs reach production, static analysis of infrastructure-as-code (IaC), automated configuration validation against secure baselines, and enforced runtime policies must become non-negotiable steps.

Treating Configuration Drift as an Ongoing Threat

Configuration drift—the gradual divergence of runtime systems from secure intended states—is inevitable. Organizations must treat it like a live security threat by implementing continuous posture management tools that detect and remediate misconfigurations as they occur, not months later during annual audits.

A New Governance Model: Configuration as Code + Continuous Validation

Like application code, progressive API security leaders now treat configurations as critical assets requiring version control, peer review, and automated testing. Combined with continuous validation, this model ensures that every change in API exposure aligns with organizational security policies, reducing the risk of silent missteps.

Injection Attacks (SQL, NoSQL, Command Injection)

Injection attacks have plagued systems for decades, yet APIs give this old threat new, more dangerous territory to exploit. Unlike traditional web apps, APIs process massive volumes of direct input without the mediating layer of a human UI, accelerating the impact of poorly validated or unsanitized requests. Today’s attackers exploit SQL and NoSQL databases, as well as command-line interfaces, connected through APIs.

APIs: The New Injection Highways

APIs provide attackers with clean, machine-readable paths directly to sensitive business logic. If improperly validated, JSON or XML payloads can become Trojan horses that carry injection payloads directly into backend services. Modern APIs, integrated with complex microservices and cloud-native components, significantly widen the attack surface.

Beyond SQL: The Rise of NoSQL and Command Injection

Security strategies built only around SQLi (SQL Injection) are dangerously outdated. NoSQL databases, such as MongoDB or Cassandra, which are often assumed to be inherently safer, can be easily compromised through malicious payload structures that manipulate query logic. Likewise, APIs that pass input directly into shell commands without proper sanitization create lethal openings for command injections, particularly when orchestrating containerized environments.

Blind Injection: The Silent Killer

In many API environments, error responses are sanitized, and verbose messaging is suppressed, leading to a dangerous blind spot: blind injection attacks. Attackers can craft payloads that cause backend delays, side-channel errors, or timing anomalies, providing subtle clues to the weaknesses of internal systems without triggering obvious alarms.

Over-trusting “Internal” APIs: A Common Misstep

Many organizations mistakenly assume that internal APIs—those not exposed externally—are immune to injection risks. However, compromised devices, insider threats, or lateral movement from attackers within the network mean even internal APIs must undergo the same rigorous input validation, encoding, and sanitization as public-facing ones.

Defense in Depth: Moving Past WAF Reliance

While Web Application Firewalls (WAFs) offer a layer of defense against injection attacks, relying solely on them invites a false sense of security. Robust defenses demand contextual validation at the application layer, strict schema validation (for JSON and XML), prepared statements for database queries, and rigorous content filtering at every integration point.

Injection as a Regulatory Liability

In today’s regulatory landscape (GDPR, CCPA, HIPAA), a successful injection attack doesn’t just mean operational disruption—it can trigger severe legal penalties. APIs processing PII (Personally Identifiable Information), financial data, or healthcare records must demonstrate due diligence against injection threats or face mounting compliance risks.

Improper Asset Management

Regarding API security, you cannot protect what you do not know exists. Improper asset management is a silent killer in cybersecurity strategy, especially as APIs proliferate across hybrid environments. Overlooked, undocumented, or deprecated APIs quietly expand an organization’s attack surface, often without security teams realizing it until an incident occurs.

Shadow APIs: The Hidden Risks in Plain Sight

Shadow APIs—those created outside official IT governance—often fly under the radar, bypassing standard security reviews and hardening processes. Development teams are under pressure to deliver fast and frequently spin up temporary APIs for testing, integration, or MVP launches. Without structured asset discovery and lifecycle management, these APIs often linger long after their original purpose, making them a low-hanging fruit for attackers.

Orphaned Endpoints: Forgotten but Dangerous

Endpoints associated with decommissioned apps or sunset projects are rarely retired with the rigor they deserve. Improper asset management leaves these orphaned APIs active, vulnerable to exploitation through outdated libraries, unpatched dependencies, or obsolete authentication mechanisms. Attackers actively scan for these endpoints, knowing they are typically unmonitored and unprotected.

Lack of API Inventory: A Fundamental Governance Failure

Despite the growing importance of APIs, many organizations still lack a centralized, continuously updated inventory of API assets. Without complete visibility, CISOs cannot effectively assess risk exposure, prioritize vulnerability management, or comply with regulations that require clear data processing records, such as GDPR’s Article 30 requirements.

Asset Drift: The Challenge of Dynamic Environments

Cloud-native architectures introduce constant change. Microservices auto-scale, APIs are rapidly versioned, and serverless functions dynamically spin up new endpoints. In this chaos, asset drift—where deployed assets diverge from documented inventories—becomes inevitable without the use of automated discovery and classification tooling.

Moving from Manual to Automated Discovery

Relying on spreadsheets, emails, or ad hoc registries to track APIs is an untenable strategy at scale. Advanced API discovery platforms, integrated with runtime environments, continuously map exposed endpoints and flag anomalies, catching intentional deployments and accidental exposures early.

The Compliance Angle: Document or Get Penalized

Regulatory frameworks are increasingly mandating the clear documentation of data flows, processing activities, and technical assets. Incomplete or inaccurate API inventories can result in substantial fines, failed audits, and significant reputational damage. Proper asset management is no longer just good hygiene but a legal necessity.

Insufficient Logging and Monitoring

APIs are the connective tissue of modern digital ecosystems—but without sufficient logging and monitoring, they become silent liabilities. Detecting, understanding, and responding to malicious API activity requires far more than standard network or application monitoring. It requires a strategy tailored to the unique interaction patterns, data sensitivities, and dynamic behaviors of APIs.

Why APIs Need Specialized Observability

Unlike traditional apps, APIs operate on stateless, highly granular transactions that blend authentication, authorization, data processing, and business logic in a single request-response cycle. Standard logs often miss critical API-layer details such as token usage anomalies, parameter tampering, or abuse of legitimate endpoints. Specialized API observability focuses on context-rich metadata, capturing what typical logs overlook.

The Danger of Delayed Detection

API breaches can smolder undetected for months without real-time monitoring and intelligent alerting. Attackers often leverage APIs to exfiltrate sensitive data slowly, avoiding rate limits or volumetric detection thresholds. Without fine-grained visibility, security teams miss the subtle indicators of compromise until it’s too late for containment.

Logging Sensitive Data: A Double-Edged Sword

Improper logging can itself introduce risks. Logging whole request bodies, headers, or tokens without careful sanitization exposes organizations to regulatory violations and insider threats. CISOs must enforce a disciplined logging strategy that captures sufficient context for forensic analysis while redacting personally identifiable information (PII) and sensitive credentials.

Anomaly Detection Over Signature Matching

Traditional SIEM rules and static detection signatures fail against evolving API attacks. Advanced solutions leverage behavioral baselines to identify deviations, such as unexpected resource access, abnormal token usage, or sequence violations. Anomaly detection tailored for API traffic surfaces attacks that would otherwise remain hidden.

Correlating API Events Across Systems

APIs rarely operate in isolation; they trigger workflows across microservices, cloud platforms, and databases. Siloed logging prevents a holistic view of an attacker’s lateral movement. Building a centralized logging architecture that correlates API calls with downstream activities enables richer threat hunting, root cause analysis, and incident response.

Compliance Requires Audit-Ready API Logs

Regulations such as GDPR, HIPAA, and PCI-DSS increasingly demand auditable evidence of data access, modifications, and transfers. Comprehensive, immutable API logs are operationally valuable and critical to passing compliance audits and demonstrating due diligence in security incidents.

Transforming API Security Risks into Competitive Advantage

APIs are no longer just technical tools; they are fundamental to digital business strategy. For CISOs, CFOs, and security leaders, addressing API security risks is no longer optional or a reactive measure. Organizations that proactively build robust API security postures are not just defending themselves but positioning their businesses for strategic advantage, customer trust, and long-term resilience.

Turning Visibility into Business Intelligence

Organizations that deeply monitor, log, and analyze API interactions can unlock insights beyond threat detection. Behavioral baselines reveal customer patterns, product adoption metrics, and operational inefficiencies. API observability, when executed securely, becomes a source of competitive intelligence that informs security operations and business growth.

Risk Management as a Differentiator

In an environment where breaches instantly erode brand equity, demonstrable API security maturity can be a market differentiator. Enterprises that demonstrate rigorous API security controls, conduct regular third-party assessments, and possess swift incident response capabilities can position themselves as safer partners, particularly in industries that handle sensitive data, such as finance, healthcare, and critical infrastructure.

Embedding API Security into Product Development

The future belongs to organizations that view API security not as an afterthought but as an intrinsic part of product innovation. Embedding security into the API lifecycle—from design to deployment—accelerates time to market, reduces costly rework, and protects intellectual property. Security-first APIs become trust accelerators, not obstacles.

Regulatory Preparedness as Strategic Agility

Upcoming regulations will not tolerate ignorance or negligence. By operationalizing API security best practices today, enterprises create a buffer against the unpredictable waves of new compliance standards. Leaders who treat API governance as a board-level priority will confidently navigate future audits, disclosures, and public scrutiny.

The CISO’s Opportunity to Lead Transformation

API security is a rare opportunity for CISOs to expand their influence beyond traditional IT silos. By championing API governance frameworks, advocating for security-by-design principles, and tying security outcomes directly to business key performance indicators (KPIs), security leaders evolve into strategic enablers of digital transformation rather than gatekeepers of risk.