Importance of Ubiquitous Language in Domain-Driven Design

Once developers and domain experts speak the same language, production pipelines can move forward faster.

Most commercial software applications are created with a set of complex business requirements to solve specific business problems or needs. However, expecting all the software developers/architects to be experts on business domains and expecting them to know entire business functions is also impractical. On the other hand, how do we create software that brings value and has consumers who are in need of automation that will use the software? A software application cannot be just a showpiece of technical excellence, but in most cases, also real and usable of automated business excellence. The domain-driven design and models are the answers to those questions.

This short article talks about one of the key principles of Domain-Driven Design called "Ubiquitous Language" as DDD concepts, principles, and patterns bring technology and business excellence together to any sophisticated software applications that can be created and managed.

Talk Ubiquitously

Ubiquitous language is a model that acts as a universal language to help communication between software developers and domain experts.

Collaborating, learning, and defining a model brings a lot of initial communication barriers between software specialists and domain experts. So evolving domain model with practicing the same type of communications (discussions, writings, and in diagrams) within a context is paramount for successful implementations, and that sort of conversation is called Ubiquitous Language. It is structured around the domain model and extensively used by all the team members within a bounded context. It should be the medium or mode to connect all the activities of the team within the development of software.

The design team can establish deep understanding and connecting domain jargons and software entities with Ubiquitous language to keep discovering and evolving their domain models.

Ubiquitous Language	Equivalent Pseudo Code	Comments
We Administer Vaccines	AdministerVaccines {}	Not a core domain – need some more specific details
We administer flu Shots to patients	patientNeedAFluShot()	Better, may be missing some domain concepts
The nurse administers flu vaccines to a patient in standard doses	Nurse->administer vaccine(patient, Vaccine.getStandardDose())	Much better, and may be good to start with.

As we observe in the above table, there are various ways the user stories (requirements) can be given; however, the last row makes sense as it does have more clarity on what and how factors.

Hopefully, this article helps readers to get a glimpse of how DDD principles advocates and helps greater collaboration between subject matter experts, business analysts, nontechnology stakeholders with the technical/development community to produce complex domain driven systems.

[published @Dzone as well]

REST API Security Vulnerabilities

** Published at DZONE

Simple, schematic, faster to develop and quick deployments make APIs so popular and widely used. So, naturally, it brings various challenges to maintain its implementations and keep them secured from various threats, such as Man-in-the-Middle attacks, lack of XML encryptions, insecure endpoints, API URL parameters, and so on. REST API has similar vulnerabilities as a web application.

In this article, I will present a few common API vulnerabilities that every developer should be aware of and on the lookout for in their code.

API Exposing Sensitive Data and Protection Personal information, credit card information, health records, financial information, business information, and many other categories of personal information need protection, so we need to evaluate and determine the types of data being transmitted or stored and ensure critical data is protected with appropriate encryption algorithms and security measures. Some of the dos and don'ts of REST API security best practices are as follows:

• Classification of data and apply controls according to these classifications 
• Do not store sensitive information unless necessary and discard it as soon as possible. 
• Use tokenization and truncation methods to prevent the exposure of sensitive data 
• Encryption is a necessary and crucial protection measure 
• Do not implement a cache for sensitive data (or disable cache for sensitive data transactions) 
• Use salts and adaptive (configurable number of iterations) hashing methodologies for passwords 

Authentication Attacks
Authentication attacks are processes with which a hacker attempts to exploit the authentication process and gain unauthorized access. Bypass attack, brute-force attack (for passwords), verify impersonation, and reflection attack are a few types of authentication attacks. Basic authentication, authorization with default keys, and authorization with credentials are a few protection measures to safeguard our APIs.

Cross-Site Scripts
Cross-site scripts, also known as an XSS attack, is the process of injecting malicious code as part of the input to web services, usually through the browser to a different end-user. The malicious script, once injected, can access any cookies, session tokens, or sensitive information retained by the browser, or even it can masquerade the whole content of the rendered pages, XSS categorizes into server-side XSS and client-side XSS. Traditionally, XSS consist of three types; they are Reflected XSS, Stored XSS, and DOM XSS.

Cross-Site Request Forgery
Cross-site request forgery, also known as CSRF, sea-surf, or XSRF, is a vulnerability that web applications expose a possibility of the end user forced (by forged links, emails, HTML pages) to execute unwanted actions on a currently authenticated session. Synchronize token pattern, cookie-to-header token, double submit cookie, and client-side safeguards are common CSRF prevention methodologies.

Denial-of-Service (DoS) Attack
The Denial of Service is an attack intends to make the targeted machine reach its maximum load (capacity to serve the requests) quickly by sending numerous falsify requests, and so, the target system denies further genuine requests.

Injection Attack
The attacker supplies an untrusted input to the application, which gets executed/processed as a part of command or query, thus, this results in the partial or complete discourse of the application behavior and leads to consequences such as data theft, data loss, loss of data-integrity, DoS, and even leads to full system compromise.

Insecure Direct Object References
Insecure Direct Object References, or simply IDOR, is an equally harmful top API vulnerability; it occurs when an application exposes direct access to internal objects based on user inputs, such as Id, filename, and so on. You might have observed that many REST URIs expose some sort of IDs, especially for fetching resources. Let's take an example scenario to make it clear for the readers — say Bob is using an API client and he needs to get his file with ID 1001. He would need to use https://myapi.server.com/browse/file/id/1001, but assume he is trying Alice's file (1003), which he not supposed to, i.e. Bob tries to use the URL https://myapi.server.com/browse/file/id/1003, so he should be denied access. If not, then the API is exposed to the IDOR vulnerability.

Man-in-the-Middle (MITM) Attack
A Man-in-the-Middle attack is an attack from a perpetrator place in the middle of the network or communication between a genuine user and an application server. It intends to steal, eavesdrop, impersonate, and secretly relay, intercept, or alter communications including API messages between two communicating parties, besides appear as if a normal exchange of information is underway.

Replay Attacks and Spoofing
Replay attacks and spoofing, aka playback attacks, are network attacks in which a valid data transmissions (supposed to be only one time) being repeated many times (maliciously) by the attacker who spoofed the valid transaction and replays it as many times as they would like. While the server is expecting a valid transaction, it will not have any doubts as those requests is a valid transaction as per the server. However, it is a masqueraded request and leads to catastrophic effects for the clients. The protection measures include a one-time password with session identifiers, TTL (Time-To-Live) measures MAC implementation at the client side, and including the timestamps in the request along with secure protocol such as Kerberos protocol prevention, secure routing, and Challenge-Handshake Authentication Protocol (CHAP).

"One of the best REST API books for beginners" - BookAuthority