This article covered some easy-to-use tips on Java API security and performance, including some advice on framework choices for securing API keys and developing Web Services.

Programmers love to use apis! Such as building apis for app applications or as part of microservices architecture. Of course, using an API is supposed to make your job easier. Efforts to simplify development and increase productivity sometimes mean finding new libraries or processes (or reducing processes). For many development teams, managing certification and access control for their apps and apis can be time consuming, so we want to share some tips that can save you time, reduce code, and make your apps more secure and maintainable. A bit of background: Okta is a Java application built using the Spring framework based on REST and JSON APIS. Our company’s applications store users’ identity credentials and other companies’ sensitive data, so for us, security is of the utmost importance. So my first request for these tips is that they help make your Java applications more secure.

These recommendations should be common to any type of Java application. They’ll help you code faster, but with less code and more security: it’s really a win-win-win!

Seriously, don’t try to implement security code yourself. It’s too hard.

Almost everyone knows to avoid implementing algorithms such as encryption. Similarly, the rest of your application’s security stack can be expensive and risky. You are likely to make some mistakes. Since 1999, 89,373 Cves (Common Vulnerabilities and Exposures) have been published. And most of the discoverers that have been published are very smart people.

You might think that dealing with a simple use case (such as validating a user’s password) would be a simple matter — all you’re doing is comparing a pair of strings. That would be a mistake. You need to validate password hashes, audit login attempts, and reduce attacks on dictionaries, which is just the tip of the iceberg. Your best bet is to use an existing, mature library or framework, such as Apache’s Shiro or SpringSecurity, and let those frameworks handle complex security issues.

#2. Use TLS, Always! Always use TLS! It’s 2017, and all websites should be using HTTPS, even the corporate Intranet. Let’s Encrypt makes HTTPS easy and simple, which means you can no longer use insecure self-signed keys! You can even set up Tomcat or Nginx instances with certificate authentication locally.

Making your application require TLS(HTTPS/SSL) is as simple as one line of code, and everyone should do it! If you use the Apache Shiro framework, you only need to set the properties:

[urls]/** = sslCopy the code

If you use Spring Security, you simply call a method when setting up HttpSecurity.

http.requiresChannel()
.anyRequest().requiresSecure();Copy the code

In Spring Boot, you only need to set a few properties, as follows:

server.port=8443
server.ssl.key-store=classpath:keystore.jks
server.ssl.key-store-password=secret
server.ssl.key-password=another-secretCopy the code

#3. Create a Web Service using Spring Boot

Spring Boot is a simplification of the Spring platform that makes it easy to write Spring applications, such as the 12 Factors to Consider in Apps, with very little code. If you’re still coding with War packages, Spring Boot is worth learning. Spring Boot can be used for complex, different types of applications. For example, you can set up an OAuth resource server with a simple annotation (@enableresourceserver), or change its port through simple properties:

server.port = 8090Copy the code

If you don’t like SpringBoot, you can use Dropwizard to build the JAX-RS stack.

#4. Monitor application and performance metrics

It’s hard to detect errors without any data. Spring Boot uses the Actuator to make it easy to collect data by adding a dependency in the application, as follows:

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> 'Java Learning exchange QQ group: 589809992 Let's learn Java together!Copy the code

In the browser, enter /health or /metrics after accessing the application address to check the application health status or metrics. The Dropwizard framework does the same with/HealthCheck and /metrics.

Here is the output from the Spring Boot app via /metrics:

    {
    "classes": 7704,
    "classes.loaded": 7704,
    "classes.unloaded": 0."counter.status.200.metrics": 1,
    "gauge.response.metrics": 99.0."gc.ps_marksweep.count": 2."gc.ps_marksweep.time": 272,
    "gc.ps_scavenge.count": 8,
    "gc.ps_scavenge.time": 136,
    "heap": 3728384,
    "heap.committed": 470016,
    "heap.init": 262144,
    "heap.used": 207793,
    "httpsessions.active": 0."httpsessions.max": 1,"instance.uptime": 25020,
    "mem": 529086,
    "mem.free": 262222,
    "nonheap": 0."nonheap.committed": 60608,
    "nonheap.init": 2496,
    "nonheap.used": 59067,
    "processors": 8,
    "systemload.average": 5.56103515625."threads": 24,
    "threads.daemon": 22."threads.peak": 28."threads.totalStarted": 32."uptime": 37182}Copy the code

#5. Protect sensitive information

It’s true that people think API keys are insecure. The key is sent by email or controlled by the source code management system. Maybe that’s why they seem less secure than passwords, but they’re just as sensitive. If you need to store the API key in a file, be sure to grant limited access to the file. For example, we recommend in the private directory

To store Okta’s YAML files and give the file owner read-only permission.

$ chmod u=r,go-rwx ~/.okta/okta.yamlCopy the code

If you are creating apis for users using your APP, remind them that.ssh files will be placed in your ~/.ssh directory if they have not set permissions, or if they have not set permissions. GitHub puts them in the “danger zone” to remind users, which is useful.