Review your Application Architecture Today !


Application architecture review can be defined as reviewing the current security controls in the application architecture. This helps a user to identify potential security flaws at an early stage and mitigate them before starting the development stage. Poor design of architecture may expose the application to many security loopholes. It is preferable to perform the architecture review at the design stage, as the cost and effort required for implementing security after development is high.

This document can be considered as the secure design guideline for the architects or as a checklist for penetration tester to perform application architecture review as a part of the overall security assessment.

The following diagram shows some of the primary issues that must be addressed at the designing stage.

While doing the architecture review we can primarily focus on the following areas:

  1. Application Architecture Documents
  2. Deployment and Infrastructure Considerations
  3. Input Validation
  4. Authentication
  5. Authorization
  6. Configuration Management
  7. Session Management
  8. Cryptography
  9. Parameter Manipulation
  10. Exception Management
  11. Auditing & Logging
  12. Application Framework and Libraries

Additional category or points under any category can be added as per the requirement. Let’s have a look at each area separately:

Application Architecture Documents:

The first thing to look for is the availability of the application architecture document. Every application should have a properly documented architecture diagram with a high-level explanation of the above points and a network connectivity diagram showing how different component are placed and secured.

Deployment and Infrastructure Considerations:

Review the infrastructure on which the application is deployed. This can include reviewing the network, system, infrastructure performance monitoring, etc.

Some of the points which should be taken into consideration are as follows:

  • Components required for the application: What is the OS supporting the application, hardware requirement, etc.?
  • Restrictions applied on the firewall: Review the firewall policies defined for the application. What type of traffic is allowed and what type of traffic is blocked?
  • Port and Service requirement: An application may communicate with other application as well. Identify which ports and services are required to be open for the application.
  • Component Segregation: Components of the application should be segregated from each other. For example, the application server and database server should not reside in the same machine.
  • Disable clear text protocol: Ports running clear text services like (HTTP, FTP, etc.) should be closed and not used for any part of the application.

Input Validation

Weak input validation is one of the main reasons for application security weakness. Proper input validation can help in preventing many attacks like Cross-Site Scripting, SQL Injection, etc. The validation should be applied on every input field (including the hidden form field) of all the pages. The best practice is to use a centralized approach.

Some of the points which should be taken into consideration are as follows:

  • Mechanism to validate the user inputs: Check if the application is validating the user input or processing the input as it is.
  • Bypassing the validation: Check how the user input is being validated. Is it possible to bypass the validation, for example, encoding the input? Identify if input validation depends on the application framework. Check whether there is any vulnerability in the framework through which a user can bypass the validation.
  • Centralized approach: If custom implementation to validate the user input is present, check whether the approach is centralized.
  • Validating across all the tiers: As a best practice, validation should be applied on all the layers, i.e. business layer, data layer, etc.
  • Addressing SQL Injection issue: Input validation helps in mitigating SQL Injection issue to some extent. Check whether the application is safe against the SQL Injection vulnerability by using parameterized query in the back end.


Authentication is the act of verifying a user’s identity. In the application, it is achieved by providing the username and password. Weak authentication mechanism can result in bypassing the login process and accessing the application. This can lead to a major compromise. The application should be designed with strong authentication.

Some of the points which should be taken into consideration are as follows:

  • Authentication control on the server side: Make sure the credentials are verified at the server side and not on the client side. Client-side validation can be easily bypassed.
  • Secure channel for authentication: Login credentials should always be sent through an encrypted channel. Credentials going through a clear text channel can be easily sniffed by the attacker.
  • Check whether the login page is served over HTTP protocol. Check whether the application can be accessible on any other port where SSL certificate is not implemented.
  • Change password page: Check whether the Old Password field is present in the Change Password page and verified as well.
  • Strong password policy: An application should be configured to accept strong passwords only. Weak passwords can be brute forced easily.
  • Authentication cookie: Check if SSL is implemented on an entire application and the authentication cookie is not sent in clear text on any page.
  • Service account: Service account is an account under which a service application is running. A service account is required for the application and communicating with the database should have a restrictive set of privilege.
  • Default framework password: Many application framework comes with a default password. Make sure the password is changed to a non-guessable strong password.


Authorization determines which resources can be accessed by the authenticated user. Weak authorization control can lead to Privileges Escalation attacks.

Some of the points which should be taken into consideration are as follows:

  • Privilege escalation and spoofing: Privilege escalation happens when a user gets access to more resources than they are allowed or when the user can perform additional actions than they are allowed. Check the controls present when the user tries to escalate his/her privilege through manipulating the request or by directly accessing the unauthorized page/resource.
  • Direct object reference: Check whether the application provides direct access to the objects based on the user-supplied input. This may allow the attacker to access the resources belonging to other users by bypassing the authorization. For example, downloading the invoices/statement of other users.

Configuration Management

Weak configuration should be avoided. Any sensitive information being stored in the configuration file can be extracted by the attacker.

Some of the points which should be taken into consideration are as follows:

  • Secure Hardening: Make sure all the components required for the application are updated and the latest patches are applied on them. The default configuration should be changed wherever possible.
  • Sensitive Data: Sensitive data like database connection string, encryption key, admin credentials or any other secret should not be stored as clear text in the code. Check whether the configuration file is secured against the unauthorized access.
  • Persistent cookie: Storing sensitive data as plaintext in a persistent cookie should be avoided. The user can see and modify the clear text data. Check if the application is storing the clear text data in a persistent cookie.
  • Passing sensitive data using GET protocol: The GET protocol sends the data in the query string. Sensitive information going in a GET request can be accessed from the browser history or logs.
  • Disable unused methods: Verify that the application accepts only GET and POST methods. Other methods like TRACE, PUT, DELETE, etc. should be disabled.
  • Sensitive data over HTTP: Communication between the components, such as between application server and database server, should be encrypted.

Session Management

The session is the track of the user activities. Strong session management plays an important role in the overall security of the application. Weakness in the session management may lead to serious attacks.

Some of the points which should be taken into consideration are as follows:

  • Use framework’s default session management: Custom session management can have multiple vulnerabilities. Ensure there is no custom manager is being used and the application framework’s default session management is used.
  • Ensure session management best practices are followed:
    • The session ID is random, long and unique.
    • The session is invalidating after logout.
    • The session ID is changing on successful authentication and re-authentication.
    • The session ID is not going in URL.
    • The session is timed out after a certain period of inactivity.
    • The session ID is going insecure channel like SSL.
    • Check whether cookie attributes (HttpOnly, Secure, path and domain) are secured.


Applications frequently use cryptography to secure the stored data or to protect the data in transit over an insecure channel.

Some of the points which should be taken into consideration are as follows:

  • Custom Implementation: Designing a dedicated encryption mechanism may lead to weaker protection. Secure cryptographic service provided by the platform should be used. Check what type of encryption is being used in the application.
  • Encryption Key management: Check whether there is any policy on encryption key management, i.e., Key generation, distribution, deletion, and expiration.
  • Securing encryption keys: Encryption keys are used as an input to encrypt or decrypt the data. If encryption keys are compromised, the encrypted data can be decrypted and hence, will be no longer be secure.
  • Key recycle policy: The key should be recycled after a certain period. Using the same key for a long time is not a safe practice.

Parameter Manipulation

With Parameter Manipulation attacks, the attacker modifies the data going from application to the web server. This can result in unauthorized access to services.

Some of the points which should be taken into consideration are as follows:

  • Validate all inputs from the client: Validation applied on the client side may reduce the load on the server but relying only on client-side validation is not a safe practice. Client-side validation can be bypassed using a proxy tool. Check whether validation is applied on the server as well.
  • Do not rely on HTTP header: Security decision in the application should not be based on the HTTP header. If the application is serving any page by checking only the “referrer” header, then an attacker can bypass this by changing the header in a proxy tool.
  • Encrypt the cookie: Cookies can have data that is being used on the server to authorize the user. This type of data should be protected against unauthorized manipulation attacks.
  • Sensitive data in view state: View state in an ASP.NET application can have sensitive data that is required to take the authorization decision on the server. Data in view state can be tempered if MAC (message authentication code) is not enabled. Check whether view state is protected using MAC.

Exception Management

Insecure exception handling can expose the valuable information, which can be used by the attacker to fine-tune his attack. Without exception management, information such as stack trace, framework details, server details, SQL query, internal path and other sensitive information can be exposed. Check whether centralized exception management is in place, with minimum information being displayed.

Auditing & Logging

Log files contain the record of the events. These events can be a success or failed login attempt, data retrieval, modification, deletion, network communication, etc. The logs should be monitored in real time.

Some of the points which should be taken into consideration are as follows:

  • Logging enabled: Check if logging is enabled for application and platform level as well.
  • Log events: Logs should be generated for all security-level important events like successful and failed authentication, data access, modification, network access, etc. The log should include time of the event, user identity, location with machine name, etc. Identify which events are being logged.
  • Logging sensitive data: An application should not log sensitive data like user credentials, password hashes, credit card details, etc.
  • Storage, security, and analysis:
    • The log file should be stored on a different partition than the one on which the application is running. The log file should be copied and moved to permanent storage for retention.
    • The log files must be protected against the unauthorized access, modification or deletion.
    • The log file should be analyzed on a regular interval.

Application Framework and Libraries

Make sure that the application framework and libraries are up to date and relevant patches are applied on them. Verify that there is no default password being used in the framework (admin/admin, tomcat/tomcat, etc.). Check whether the old or vulnerable framework is in use.


The above points represent the key areas for secure designing of the application. Implementing these points at the designing stage can reduce the overall cost and effort to secure the application. If the application is already deployed, secure architecture review is an important part of the overall security assessment and can help in fixing the existing vulnerabilities and improving the future design.

Hits: 1626

OWASP API Security Top 10 – 2019(1st Version)

OWASP API Security Top 10 – 2019

The FIRST Edition from OWASP for API Security

What is API Security?

A foundational element of innovation in today’s app-driven world is the API. From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.

API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs).

API Security Risk

The OWASP Risk Rating Methodology was used to do the risk analysis. The table below summarizes the terminology associated with the risk score.

Threat AgentsExploitabilityWeakness
API SpecificEasy: 3 Widespread 3 Easy 3 Severe 3Business
Average: 2 Common 2 Average 2 Moderate 2
Difficult: 1 Difficult 1 Difficult 1 Minor 1

This approach does not take the likelihood of the threat agent into account. Nor does it account for any of the various technical details associated with your particular application. Any of these factors could significantly affect the overall likelihood of an attacker finding and exploiting a particular vulnerability. This rating does not take into account the actual impact on your business. Your organization will have to decide how much security risk from applications and APIs the organization is willing to accept given your culture, industry, and regulatory environment. The purpose of the OWASP API Security Top 10 is not to do this risk analysis for you

Brief summary of each threat:

A1:2019 – Broken Object Level Authorization:

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.

A2:2019 – Broken Authentication:

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall.

A3:2019 – Excessive Data Exposure:

Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client’s state, servers receive more-and-more filters which can be abused to gain access to sensitive data.

A4:2019 – Lack of Resources & Rate Limiting:

Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.

A5:2019 – Broken Function Level Authorization:

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

A6:2019 – Mass Assignment:

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

A7:2019 – Security Misconfiguration:

Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

A8:2019 – Injection:

Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

A9:2019 – Improper Assets Management:

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

A10:2019 – Insufficient Logging & Monitoring:

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Further Reading and References:

Please find the complete PDF  or visit the OWASP Website.

Hits: 241