Software Security Testing – OWASP
ModSecurity is an open source, cross-platform web application firewall (WAF) module. Known as the “Swiss Army Knife” of WAFs, it enables web application defenders to gain visibility into HTTP(S) traffic and provides a power rules language and API to implement advanced protections.

Install this before web application. Access application through Mod Security and see the magic. Read above documentation. This is very useful in Dev/QA environments to test OWASP issues ahead of the time.

The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers*. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. Its also a great tool for experienced pentesters to use for manual security testing.


Software Architect Catalogue

IBM Cloud Catalog

Amazon Catalog

Architectural Patterns

Software Security Patterns

Integration Patterns

Software Architecture


Securing Passwords in Production Deployments


There is no one solution for all problems.

Use Case 1:
We run three instances in production, each instance serve one version of API and having three different passwords with same variables. We store them on each instance.

Use Case 2:
We run 100+ UI instances with same user id/password

Use Case 3: Time bound
We want to schedule password changes.
Use Password 1 until December 31st,
Use Password 2 from Jan 1st onwards.

Use Case 4: Versioning
When you rollback changes, we want to roll back passwords too.

We need to agree on Use case and design solution accordingly.


Using security as service – Means getting passwords from rest calls with token id too is going to cause single point of failure. We need to make sure that Vault or similar software is having high availability by running in more than one instance.



Hardening Servers like Tomcat, Play, Spring, Apache, JBoss, Weblogic, …etc

Development community develops web applications and deploys to server.
Later they do the same in production.
This will lead to potential security issues.

Things to consider/do

1. Use Charles Web Proxy and check entire traffic of site through testing.
1. Make sure that there is not 404, 500 related issues.
2. Identify duplicate calls
3. Minimize / reduce service calls
4. Protect important data

2. Out of the box, many servers comes with many URLs to manage them.
Identify all through admin manual and protect them with strict passwords.
Never expose admin URLs outside network

3. Perform port scan and protect respective ports through firewall rules or by other ways.

4. Undeploy sample applications, examples, settings from production servers

At the end attackers will get access to your system through default passwords or
They can do denial-of-service (DoS) attack.

Converting out of the box Tomcat to production ready is called “Hardening process” .


Software Threat Modeling

When security breach happens….it is loss to customer and company. We can handle this in two ways. Reactive: Wait until it happens and take care of it. Proactive: do software threat modeling, fix the issues before they surface, and cause trouble.

Many people think that threat is always outside firewall. Not true. It can happen from inside too in two ways. Attacker who penetrated firewall and access systems though compromised id/password. Frustrated employees or contractors who cause the trouble.

When it comes to security, prevention is better than cure. Many companies neglect security by looking at estimated budgets by security team. Please contact Software Architect / Security Architect who can help you to protect your customers and business.



Attacks through XML Payloads

When XML Payloads are permitted, system can be attacked through XML Data.

The Over sized Payload Attack: Sending huge files and causing DOS (Denial of Service).
The DOM Parser Attacks: Sending too complex lengthy data and causing out of memory in system.
SQL Injections: If data is used directly to insert into database through statements.

Development Side:
1. Define strict XSDs.
2. Avoid maxOccurs=”unbounded” and limit with max values
3. Don’t parse files/data if it exceeds configured size.

System Side:
Better to use XML Firewalls
Forum Sentry API Gateway:
Cisco ACE XML Gateways



Eight Privacy Principles – from OECD

All people/companies must know these eight privacy principles


Collection Limitation Principle

7. There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

Data Quality Principle

8. Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.

Purpose Specification Principle

9. The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

Use Limitation Principle

10. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except:

  • a) with the consent of the data subject; or
  • b) by the authority of law.

Security Safeguards Principle

11. Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.

Openness Principle

12. There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.

Individual Participation Principle

13. An individual should have the right:

  • a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him;
  • b) to have communicated to him, data relating to him within a reasonable time;
    at a charge, if any, that is not excessive;
    in a reasonable manner; and
    in a form that is readily intelligible to him;
  • c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and
  • d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.

Accountability Principle

14. A data controller should be accountable for complying with measures which give effect to the principles stated above.


Above text was copy pasted from

The Organisation for Economic Co-operation and Development (OECD)